10041 - [PP]enumerating a folder's contents shouldn't resolve aliases

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P2)

Description

[Robert John Churchill]

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

Comment 1

[Robert John Churchill]

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.

Comment 2

[Doug Turner (:dougt)]

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?

Comment 3

[Robert John Churchill]

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?

Comment 4

[Doug Turner (:dougt)]

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.

Comment 5

[Doug Turner (:dougt)]

Fixes just checked in.

Comment 6

[Eli Goldberg]

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.)