Closed
Bug 38481
Opened 24 years ago
Closed 21 years ago
Mac nsIFile is being FAR too eager at resolving aliases
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: mozilla, Assigned: ccarlen)
Details
(Whiteboard: [nsbeta3-])
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•24 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•24 years ago
|
||
scott is this something that you can investigate?
must fix by PR3, otherwise rjc will need to revert back to use nsFileSpec... :-)
Keywords: nsbeta3
Comment 5•24 years ago
|
||
take a look at comment in 40750
Comment 6•24 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•24 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•24 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•24 years ago
|
Whiteboard: [nsbeta3+]
Updated•24 years ago
|
QA Contact: leger → kandrot
Updated•24 years ago
|
OS: All
Target Milestone: M17 → ---
Assignee | ||
Comment 13•24 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 15•21 years ago
|
||
2 years later... WFM Moz 20030321 OSX. Mozilla CFM/Classic build is dead.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•