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.
Summary: nsIFile is being FAR too eager at resolving aliases → Mac nsIFile is being FAR too eager at resolving aliases
scott is this something that you can investigate?
too much feature work to look at this in m16.
Target Milestone: --- → M17
must fix by PR3, otherwise rjc will need to revert back to use nsFileSpec... :-)
take a look at comment in 40750
conrad, this is the first optimization we should make. There already is the the followLink flag. We should start honoring it.
Assignee: dougt → conrad
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.
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.
Starting on this soon.
Status: NEW → ASSIGNED
changing to new email
Assignee: conrad → ccarlen
Status: ASSIGNED → NEW
re-accepted at new email
Status: NEW → ASSIGNED
minusing per PDT rules.
Whiteboard: [nsbeta3+] → [nsbeta3-]
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
I do not see this behavior in 20030311 OSX. WFM?
OS: All → Mac System 8.5
2 years later... WFM Moz 20030321 OSX. Mozilla CFM/Classic build is dead.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.