nsIFile returns different error codes if the file in question is already missing

NEW
Unassigned

Status

()

enhancement
P3
normal
4 months ago
29 days ago

People

(Reporter: mossop, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

When nsIFile.remove is called for a path that is already missing we return different error codes depending on the platform. See bug 1519184 for an example of where that has bitten us.

OSX and Linux return NS_ERROR_FILE_TARGET_DOES_NOT_EXIST. I haven't dug too deeply but I suspect it is a result of the unix implementation checking for the presence of a symlink first (https://searchfox.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#1026).

Windows returns the probably more sane NS_ERROR_FILE_NOT_FOUND.

We should either make all return the same thing or at least audit existing uses of nsIFile.remove to make sure they are checking the return code correctly.

nsIFile.isDirectory also exhibits this issue, probably other methods too :(

Summary: nsIFile.remove returns different error codes if the file in question is already missing → nsIFile returns different error codes if the file in question is already missing
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.