296181 - nsLocalFileWin.cpp nsDirEnumerator::Init NS_ERROR_FAILURE case for PR_OpenDir

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[timeless]

The comment says // not a directory?

as it happens, i'm in a really strange position.

i have maze
d: is a cdrom on \\workstation
d: is a hard drive on \\devbox

i'm running mozilla on \\workstation
on workstation,
r:
it's a mapped network drive to \\devbox\root
it has a path
r:\mozilla
which is a junction to d:\profile\mozilla

r:\mozilla\all-i686-pc-cygwin\dist\bin\test exists (mostly)
r:\mozilla\all-i686-pc-cygwin\dist\bin\test\components is a junction to
r:\mozilla\all-i686-pc-cygwin\dist\bin\components

now, there's a minor problem with this maze. when viewed from \\devbox, r: is a
subst instead of a net use, and everything it references exists. (everything
works fine on \\devbox, even if you use net use instead of subst, but
theoretically it's slower.)

when viewed from \\workstation, for whatever reason, it's perfectly legal to run
an app from r:\mozilla\all-i686-pc-cygwin\dist\bin\test, and i have done so (the
app in question is mfcembed, but xpcshell or mozilla would work the same). if
you think really hard about this configuration, you'd realize that technically
i'm asking windows to run mfcembed off a cdrom drive (d:) with a path
\profile\mozilla\all-i686-pc-cygwin\dist\bin\test\, as it happens, d: => The
device is not ready. (there's no disk in the drive.) instead, thankfully, when
windows tried to run the app, it asked \\devbox to handle the entire path. i
think (although, i could be wrong) that when windows tries to handle xpcom's
registration requests, which involve visiting the components directory, it
decides to manually parse the pieces of the reparse point, and ends up talking
to the cdrom drive (d:) at which point it gives up.

actual results:
nsDirenumerator::Init returns the generic NS_ERROR_FAILURE indicator and
eventually bad things happen :)

expected results:
I think this code can be changed to give a better error return.

fwiw, filemon indicates:
OPEN (Open Access: All)
r:\mozilla\all-i686-pc-cygwin\dist\bin\test\components\*
NAME INVALID

OPEN (Open Directory Access: All)
r:\mozilla\all-i686-pc-cygwin\dist\bin\test\components\
SUCCESS

DIRECTORY (FileBothDirecoryInformation: *)
r:\mozilla\all-i686-pc-cygwin\dist\bin\test\components\
PATH NOT FOUND

Visual Studio (7.1) in its file>open dialog gives the following error:
r:\mozilla\all-i686-pc-cygwin\dist\bin\test\components refers to a location that
is unavailable. It could be a hard drive on this computer, or on a network.
Check to make sure that the disk is properly inserted, or that you are connected
to the Internet or your network, and then try again. If it still cannot be
located, the information might have been moved to a different location.

anyway, in short, i think NS_ERROR_FILE_NOT_FOUND makes more sense than
NS_ERROR_FAILURE :).

Comment 1

[Doug Turner (:dougt)]

mass reassigning to nobody.