Doug, as we talked about, enumerating a folder's contents via nsIFileSpec et.al. should NOT resolve aliases on the Mac before returning the item. Doing so makes it very hard to fully browse the Mac's file system. Thanks! Robert
I'm marking this for M9 as I'm hoping its a trivial fix [just remove the ResolveAlias() call, or its equivalent?] and it'll get browsing the Mac's FS back up to snuff.
Status: NEW → ASSIGNED
QA Contact: mcmullen → rjc
Yes, we spoke about this. I am sure the fix is simple, but I am concerned a bit about how this will effect the users of nsFileSpec. If you get a nsFileSpec from an Iterator, you are now not certain if it is an alias or a "true" file. In every instance, you must check if it is an alias and if it is resolve it. (I believe that this is what waterson was drumming). What I would like to do is add an additional API entry point on the mac for this. The proto would look like : nsDirectoryIterator::nsDirectoryIterator( const nsFileSpec& inDirectory, int inIterateDirection, PRBool resolveAlias); Does this sound good?
Actually, no, I don't like that. :^( Chris pointed out that nsDirectoryIterator could return an alias, and instead of requiring everyone to add a special #ifdef XP_MAC check that would resolve it if it was an alias, routines like opening up a stream, etc, should do the magic to resolve aliases before opening them. That seems like the right approach. What do you think about that?
Having the stream do this conversion is cool, but what about just the vanilla nsFileSpec returned from the iterator? Suppose I get a nsFileSpec back from this iterator and I want to copy it to another location. Do I resolve in this situation? If I do, then you can not ever manipulate an alias returned from an iterator. If I do not, then everywhere I use an iterator, I have to do this resolve myself and that would suck.
Summary: enumerating a folder's contents shouldn't resolve aliases → [PP]enumerating a folder's contents shouldn't resolve aliases
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Fixes just checked in.
Bulk moving to XPCOM, in preparation for removal of XP File Handling component. (XPFH has received two bugs in ~5 months, and is no longer in active use.)
Component: XP File Handling → XPCOM
You need to log in before you can comment on or make changes to this bug.