38481 - Mac nsIFile is being FAR too eager at resolving aliases

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect, P3)

Description

[Robert John Churchill]

Dougt, I switched over some of my code to using nsIFile (instead of nsFileSpec)
and am seeing some very poor performance characteristics.

Basically, when enumerating the contents of a folder (on Mac), it looks like
nsIFile is trying to resolve each item... and, if the item, happens to be an
alias to an unmounted volume or file server, the Mac "goes to sleep" for over a
minute for EACH alias.

As an example:  mount a remote AppleShare volume, create an alias to the volume,
and put the alias on your Mac's desktop. Be sure to then UNMOUNT the AppleShare
volume so that it isn't available. Then, in Mozilla bring up a file listing for
your desktop, such as "file:///Hard%20Disk/Desktop%20Folder" and watch your Mac
be crushed.

This is important to fix, otherwise I can't really use nsIFile.

Comment 1

[Doug Turner (:dougt)]

changing summary

Comment 2

[Doug Turner (:dougt)]

scott is this something that you can investigate?

Comment 3

[Doug Turner (:dougt)]

too much feature work to look at this in m16.

Comment 4

[Cathleen]

must fix by PR3, otherwise rjc will need to revert back to use nsFileSpec...  
:-)

Comment 5

[Doug Turner (:dougt)]

take a look at comment in 40750

Comment 6

[Doug Turner (:dougt)]

conrad, this is the first optimization we should make.  There already is the the
followLink flag.  We should start honoring it.

Comment 7

[Robert John Churchill]

Note: It looks like nsIFile resolves aliases even for simple operations like 
getting the last modified date on a file system item.  That means, for example, 
that if we try and stat a Mac alias to show its last modified time, we can't...  
even though we really want the last modified date of the alias, not the real 
file it points to.

Comment 8

[Conrad Carlen]

Honoring the follow links flag should help - or at least allow it to be 
controlled. Another problem is that this object uses 3 FSSpecs and possibly a 
path to specify a file. This wastes memory and makes the code a little 
convoluted. I will address these things, first follow symlinks, then efficiency.  

Comment 9

[Conrad Carlen]

Starting on this soon.

Comment 10

[Judson Valeski]

changing to new email

Comment 11

[Conrad Carlen (not reading bugmail)]

re-accepted at new email

Comment 12

[Judson Valeski]

minusing per PDT rules.

Comment 13

[Conrad Carlen (not reading bugmail)]

Setting to future pending the upcoming reworking/refactoring of the nsIFile. One
part of that is to deal with symlinks in a clearer way. At that point, the Mac
impl will be improved WRT honoring the followSymlinks attribute.

Comment 14

[Frankie]

I do not see this behavior in 20030311 OSX. WFM?

Comment 15

[Frankie]

2 years later... WFM Moz 20030321 OSX.

Mozilla CFM/Classic build is dead.