Closed
Bug 10041
Opened 25 years ago
Closed 25 years ago
[PP]enumerating a folder's contents shouldn't resolve aliases
Categories
(Core :: XPCOM, defect, P2)
Tracking
()
RESOLVED
FIXED
M9
People
(Reporter: mozilla, Assigned: dougt)
Details
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
Reporter | ||
Updated•25 years ago
|
Target Milestone: M9
Reporter | ||
Updated•25 years ago
|
Priority: P3 → P2
Reporter | ||
Comment 1•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
QA Contact: mcmullen → rjc
Assignee | ||
Comment 2•25 years ago
|
||
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?
Reporter | ||
Comment 3•25 years ago
|
||
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?
Assignee | ||
Comment 4•25 years ago
|
||
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
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 5•25 years ago
|
||
Fixes just checked in.
Comment 6•25 years ago
|
||
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.
Description
•