133617 - nsLocalFileMac::GetParent doesn't return null at top of volume

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Bradley Baetz (:bbaetz)]

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.

Comment 1

[Conrad Carlen (not reading bugmail)]

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.

Comment 2

[Bradley Baetz (:bbaetz)]

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.

Comment 3

[Darin Fisher]

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.

Comment 4

[Conrad Carlen (not reading bugmail)]

Alright - put that way, you're right. Easy to fix.

Comment 5

[Conrad Carlen (not reading bugmail)]

This is specific to the old Mac file impl, which is dead. The new impl, in
nsLocalFileOSX, does the right thing here.