1721363 - nsIFile::Exists lies about whether UNC servers exist

Status: NEW

(Core :: XPCOM, defect, P3)

Description

[:Gijs (he/him)]

STR:

1. in the browser console, for any \\server\ that exists on your network (can be your own machine!), run: new FileUtils.File("\\\\server\\").exists()

ER:

true

AR:

false

This is because:

(In reply to :Gijs (he/him) from bug 1714583 comment #12)

Root cause inside XPCOM is that Exists() calls ResolveAndStat() which calls GetFileInfo which calls the Windows API GetFileAttributes, which promptly returns an error, which we don't understand.

It's even documented on MSDN that this will happen, though:

If you call GetFileAttributes for a network share, the function fails, and GetLastError returns ERROR_BAD_NETPATH. You must specify a path to a subfolder on that share.

Which is all well and good but doesn't really help in terms of saying what you should do to check if the server name is valid.

The only problem is, it's not clear to me how this should be fixed (though at a minimum, it'd be neat if we handled the 161 ERROR_BAD_NETPATH error return value).

Comment 1

[Beth Rennie [:beth] (she/her)]

Really, we shouldn't accept \\share as a valid path for nsIFile. UNC server paths are only valid if they have a share name (.e.g \\server\share) and a UNC path pointing at a share name does not have a parent., e.g. new FileUtils.File("\\\\server\\share").parent should return null.

This would also fix the issue with bug 1714583 because we wouldnt iterate all the way up to the server name.