Brodie Thiesfield wrote:
I initially understood that nsIFile was for syntactically valid, absolute paths only. Is this correct, or is it also valid to use nsIFile for relative path fragments, e.g.
"file.txt" (file.txt in CWD for process) "foo/file.txt" (file.txt in CWD/foo for process) "c:file.txt" (file.txt in CWD for c:)
For instance, if a new instance of nsIFile is created (thus the contained path is empty), is it valid to do an Append()?
None of the above example are guaranteed to work in all implementations of nsIFile.
The way we had it in mind was to create nsIFile from the nsIDirectoryService who knew about absolute file locations. Then, in a sense, nsIFile's were abstracted from knowing the absolute file paths -- a required for Mac OS Classic.
If you create a empty nsIFile, and Append, the nsIFile may or may not be valid -- the interface doesn't specify.
It would be worthwhile to specify this in the IDL files and to ensure that all of the implementations abide by the spec. What I've seen so far is that the Windows implementation at least (and so probably others too) isn't abiding by the spec. (ref GetParent).
If it is illegal to Append a path to an uninitialized nsIFile, then such an attemp should be spec'd to return an error of NS_ERROR_NOT_INITIALIZED.
Similarly the valid paths which can be set using InitWithPath needs to be better spelled out. i.e. Is any of the paths above valid.
Note that if the only valid path is a fully described path, since AppendPath/AppendRelativePath are not permitting ".." it makes the role of Normalize() redundant.
Brodie _______________________________________________ Mozilla-xpcom mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-xpcom
