If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Mac nsIFile is being FAR too eager at resolving aliases

RESOLVED WORKSFORME

Status

()

Core
XPCOM
P3
major
RESOLVED WORKSFORME
18 years ago
15 years ago

People

(Reporter: Robert John Churchill, Assigned: Conrad Carlen (not reading bugmail))

Tracking

Trunk
Future
PowerPC
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

(Reporter)

Description

18 years ago
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

18 years ago
changing summary
Summary: nsIFile is being FAR too eager at resolving aliases → Mac nsIFile is being FAR too eager at resolving aliases

Comment 2

18 years ago
scott is this something that you can investigate?

Comment 3

18 years ago
too much feature work to look at this in m16.
Target Milestone: --- → M17

Comment 4

18 years ago
must fix by PR3, otherwise rjc will need to revert back to use nsFileSpec...  
:-)
Keywords: nsbeta3

Comment 5

18 years ago
take a look at comment in 40750

Comment 6

17 years ago
conrad, this is the first optimization we should make.  There already is the the
followLink flag.  We should start honoring it.
Assignee: dougt → conrad
(Reporter)

Comment 7

17 years ago
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

17 years ago
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.  

Updated

17 years ago
Whiteboard: [nsbeta3+]

Comment 9

17 years ago
Starting on this soon.
Status: NEW → ASSIGNED

Comment 10

17 years ago
changing to new email
Assignee: conrad → ccarlen
Status: ASSIGNED → NEW
(Assignee)

Comment 11

17 years ago
re-accepted at new email
Status: NEW → ASSIGNED

Comment 12

17 years ago
minusing per PDT rules.
Whiteboard: [nsbeta3+] → [nsbeta3-]

Updated

17 years ago
QA Contact: leger → kandrot

Updated

17 years ago
OS: All
Target Milestone: M17 → ---
(Assignee)

Comment 13

17 years ago
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.
Target Milestone: --- → Future

Comment 14

15 years ago
I do not see this behavior in 20030311 OSX. WFM?
OS: All → Mac System 8.5

Comment 15

15 years ago
2 years later... WFM Moz 20030321 OSX.

Mozilla CFM/Classic build is dead.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.