[Classpathx-javamail] Re: Gnu mail bug

[Countach]

Chris Burdess wrote:

> Countach wrote:
>
> > > > The trouble is, this only allows for relative names. My original 
> > > > patch checked for the leading '/' so that you could use relative or 
> > > > absolute paths.
> > >
> > >
> > > The problem is that URLName.getFile returns paths that do not 
> > > include the leading '/', unlike java.net.URL. Typically, in JavaMail 
> > > applications, the mailbox is represented as a URLName rather than 
> > > the user being able to specify the exact string to pass to 
> > > getFolder(). We need a consistent way to treat file paths that 
> > > doesn't depend on a leading '/' - if you have any suggestions they 
> > > would be most welcome.
> >
> >
> > I'm not sure I understand the problem. The name argument passed to 
> > getFolder is pretty much just a string that can have any significance 
> > necessary for that type of mail repository. It is not a URL. It is 
> > the name argument that is checked to see if it starts with "/", not 
> > the url nor the File.
>
>
> The problem is, where does the string that gets passed to getFolder 
> come from? In many JavaMail applications it comes from the getFile 
> method of URLName, which cannot return a string that begins with "/".


Sorry to be thick, but it's not clear to me why you would pass the 
result of URLName.getFile() into getFolder().  I would have thought the 
only thing that is valid to pass to getFolder() is a string that has 
previously been discovered from calling  getFullName() by recursing the 
hierarchy. If you've got a URLName, shouldn't you pass it to 
Store.getFolder(URLName)?

You say you need a way to treat paths that doesn't depend on the leading 
"/",  but isn't it the Java mail spec itself that says to depend on it? 
The spec for Folder says the name is relative to the URL passed to the 
Store, unless it starts with the hierarchy delimiter -- "/" in this 
case. The IF statement I put in implements that requirement.