2009/3/6 Emmanuel Lecharny <[email protected]> > Niklas Gustavsson wrote: > >> On Fri, Mar 6, 2009 at 11:57 AM, Emmanuel Lecharny <[email protected]> >> wrote: >> >> >>> Just a small remark : it would be _very_ cool if you can extend the >>> NativeFtpFile interface with a getFile() method, because having to cast >>> the >>> object to get the so called PhysicalFile is a bit a PITA, IMHO :) >>> >>> >> >> Not sure I understand, NativeFtpFile is not an interface but an >> implementation of the FtpFile interface. And you should pretty much >> never need to get the underlying java.io.File object unless you really >> know you're working with the native file system (FtpServer never makes >> that assumption). And, since there are file system implementations >> for, for example JDBC, there might not even be a file or even a >> reasonable object we could return, at least not a java.io.File. >> >> > Never mind. David's solution is way better. Yesturday, it was late, and it > took me a bit of time to find the way to grab the File object, and I found > the solution I proposed kind of dirty, to say the least. Doing the job in > NativeFtpFile.equals() method is way cleaner.
Actually niklas had already commited the change himself when I sent the email, the only difference being that he is not swallowing the Exception as my quick code - I sent the whole code just to remark that I didn't know what to do with that exception. Still I have some concerns about the getCanonicalFile/getCanonicalPath methods because of that IOException. My thinking is that Sun is not using getCanonical... in the File equals() method because it is not safe to rely on it, otherwise, why would they provide a broken implementation of FIle.equals()? Do you know when it's likely that getCanonical* fails? Should we try a workaround in that case? If you think our code is ok as is, that's much better! > /niklas >> >> >> > > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
