106086 - nsSpecialSystemDirectory thinks /usr/local/netscape is special

Status: RESOLVED DUPLICATE of bug 101684

(Core :: XPCOM, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsSpecialSystemDirectory.cpp
contains code that returns "/usr/local/netscape" and "/usr/local/lib/netscape". 
These aren't special -- Mozilla need not be installed there or have any files
there, so I'm not sure why will still use them.

The only thing I see that actually uses this code is the res channel, which maps
resource://systemdir/ to /usr/local/lib/netscape, which on my system doesn't
exist, so I see an assertion on startup.  (nsResProtocolHandler::Init gets
NS_UNIX_LIB_DIR (or "LibD") from the directory service, which gets
nsSpecialSystemDirectory::Unix_LibDirectory.  The reason I notice this is an
assertion because nsLocalFileUnix asserts because nsLocalFile::GetURL asserts
that IsDirectory returned success, but it failed since the call to stat (through
the VALIDATE_STAT_CACHE macro) failed, the call to IsDirectory failed, and
GetURL asserts.)  Speaking of which, do we really need to stat all these files
on startup?

Comment 1

[Doug Turner (:dougt)]

two bugs i see.

Lets first tackle the res channel.  Why does it need to setup a system directory
substitution?  That just seams wrong.  Darin, do you know of any need for this?

The second, and more interesting problem, is what is a mozilla "system"
directory.  I do not think that it should be defined as
/usr/local/lib/netscape.. Maybe on unix it should be the installation point?

Conrad, do we really need to call IsDirectory in GetURL?

Comment 2

[Conrad Carlen (not reading bugmail)]

If the file object is a directory, the URL should end in '/' An assertion
(instead of failure) when the leaf does not exist and this can't be known seems
right.

Comment 3

[Doug Turner (:dougt)]

is that the spec: a file url must end in a slash if it is a directory?

Comment 4

[Darin Fisher]

dougt: it isn't standard by any means, since /tmp/foo can reference either a
file or a directory.  however, the URL parsers will think that "foo" is a file,
and make the URL's basename attribute equal to "foo."

Comment 5

[Darin Fisher]

also, i see no reason to not remove systemdir from the res protocol handler.  it
isn't used, and it isn't needed.

Comment 6

[Doug Turner (:dougt)]

Attachment: removes systemdir

Comment 7

[Doug Turner (:dougt)]

darin, sounds like we should fix the parser.  I sucks that we have to stat the
file just to tell if it is a directory for string parsing.  can you think of
anyway to avoid this?

can I get a r/sr on the patch?

Comment 8

[Conrad Carlen (not reading bugmail)]

Hey doug - this patch looks familiar. See bug 101684. That one removes
currentdrive too. Wanna close this one as a dup?

Comment 9

[Doug Turner (:dougt)]

yup.

*** This bug has been marked as a duplicate of 101684 ***

Comment 10

[Darin Fisher]

i spoke to dougt about the isDirectory call.  at the very least, it should only
be done when the file path does not end with a slash.  he said he'd be opening a
bug to get this changed.

dbaron: isDirectory is called to normalize the file path.  i believe that local
file needs the file path to be normalized in order to function correctly.  it'd
probably be some work therefore to eliminate the need for the isDirectory call.
wish it could at least be made lazy... not sure how much would be involved to do
so... probably a lot :(

Comment 11

[Conrad Carlen (not reading bugmail)]

What is the harm in attempting to determine whether the object is a directory?
It does build a URL which can be parsed more certainly. Unless determining this
is expensive (in which case the nsLocalFile impl should cache this), I don't see
the objection.

> isDirectory is called to normalize the file path.  i believe that local
> file needs the file path to be normalized in order to function correctly.

Not if we're talking about GetURL(). In that method, the path is a local var
which is built up for the purpose of converting it to a URL. It should have
nothing to do with the file's internal representation.

Comment 12

[Darin Fisher]

conrad: isDirectory is expensive because it means that we must hit the file
system (calling stat).  you're right about GetURL not needing to generate a
normalized URL.  the fact that it is a directory will only matter when the
URL is actually used to access the file system.  so, i think we could just
remove the isDirectory stuff altogether.