The nsIFile docs say: /** * Parent will be null when this is at the top of the volume. */ readonly attribute nsIFile parent; mac doesn't do this (it returns a failure code instead), and this caused failures for me when adding a "go to parent directory" link for the html file viewer. Windows doesn't either, but darin has a patch for this. I've worked arround this by not returning on failure from calls to GetPArent, and just not displaying the link if we fail, so this doesn't block me for anything, its just a correctness fix. unix does handle this correctly. peterv suggested that ccarlen gets these sort of bugs.
I think the Unix impl, if it returns null for the parent and NS_OK, is in the wrong (as are the idl comments). If the file in fact has no parent, asking for its parent would seem like a good time to return an error. If darin has a patch for this for Windows, maybe this has been debated already. Please fill me in.
Well, there is a differnece between "I have no parent" and "I hav eno clue what my parent is, because someone pulled the floppy disk out of the drive" Its not an error to not have a parent.
i agree w/ bradley. it isn't an exception to not have a parent! think about js code. it shouldn't have to wrap every call to GetParent with a try/catch block just to determine if there is or isn't a parent. returning NULL makes sense.
Alright - put that way, you're right. Easy to fix.
This is specific to the old Mac file impl, which is dead. The new impl, in nsLocalFileOSX, does the right thing here.