Doug Turner wrote:
> > Given that some of the things which are done only on local, disk based files
> > (hence the reason for nsILocalFile in addition to nsIFile) have been moved
> > into the File System service, what's left in nsILocalFile becomes so small.
> > Do we still need the distinction between the two?
> >
>
> I think that we always will want to have a nsILocalFile, even if it is empty
> (contains no functions). The reason is that you will want to know if the file
> exists on your local machine. For this, you can simply QI for this interface.
> Adding another attribute (onLocalFS) to EVERY impl of nsIFile which return false
> for all but the nsILocalFile impl seams wrong.
In working with the xp filepicker, I've run into the problem of having to find out
whether a user typed in an absolute path or a relative path, and then call the right
method (initWithPath / appendRelativePath) on nsILocalFile. This works "okay"
because right now the xp filepicker is only used on linux/unix, but it's still ugly
having to check if the typed in path starts with a "/" or not. This will become even
uglier when you try to do this for other platforms like Windows, and imo doesn't
belong here, but "behind the scenes" in the implementation of nsILocalFile.
I might however be missing the obvious, so I'm wondering, is there already a method
which allows me to get a nsILocalFile for an arbitrary path (as if I typed "more
<path>", where path can be "/foo/bar" or "baz" on linux, "c:\foo\bar" or "baz" on
Windows, etc.)?
jag
