bugGNUstep - Bugs: bug #27165, [NSFileManager enumeratorAtPath]...

Group
 
 

bug #27165: [NSFileManager enumeratorAtPath] not sorted

Submitter:  Joe Mattiello <joem>
Submitted:  Mon 03 Aug 2009 06:11:44 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Change Request Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 05 Aug 2009 07:56:10 AM UTC, comment #4: 


> It would appear that it is indeed reliant on the underlying mechanisms.


Thanks for testing that ... I guess this issue remains closed then.
I'll make a note of the behavior in the GNUstep documentation.

Richard Frith-Macdonald <CaS>
Group Member
Tue 04 Aug 2009 03:24:49 PM UTC, comment #3: 

It would appear that it is indeed reliant on the underlying mechanisms.

Test results:

  • USB Connected MacOS Extended (Case Sensitive) Volume: Alpha
  • CDROM MacOS Extended: Case insensitive Alpha [Aa-Zz]
  • WebDAV (iDisk) : Alpha (After 30 sec lag)
  • CDROM ISO 9660 (Rockridge): Case Sensative Alpha [A-Z] [a-z]
  • USB FAT32 : Timestamp order
Joe Mattiello <joem>
Tue 04 Aug 2009 01:45:18 PM UTC, comment #2: 

Derek Fawcus emailed to say:

> But on osx does it depend upon the file system type?  I believe HFS stores
> sorted directory entries,  but e.g. UFS does not.  So how will osx operate
> with a UFS formatted .dmg?


Now this suggests that the OSX implementation does not generally enumerate in alphabetical order, but probably enumerates in the order that the filesystem provides things.

In which case, encouraging developers to depend on an alphabetic order enumeration in GNUstep would be incompatible with OSX and reduce portability ... a bad thing.

So, I'm marking this bug as invalid/closed.  However, if the original submitter can confirm that the OSX behavior is to enumerate in alphabetical order on all filesystems (ie with a good test at least on UFS and network mounted (windows) filesystems where the files are known to be stored in a non-alphabetical order) then we can re-open it.

Richard Frith-Macdonald <CaS>
Group Member
Tue 04 Aug 2009 06:28:50 AM UTC, comment #1: 

I marked this as a change request since, while there is clearly no hint in the osx documentation that this enumeration should have any particular ordering and the current implementation is therefore perfectly correct, it seems like a friendly implementation detail to mimic.

Richard Frith-Macdonald <CaS>
Group Member
Mon 03 Aug 2009 06:11:44 PM UTC, original submission:  


[[NSFileManager defaultManager]
            enumeratorAtPath:currPath]; returns an enumerator for files in the path specified.
In OS X, as tested on 10.5.6, the enumerator returns objects in alphabetical order.

Bar
Bar/Foo1
Bar/Foo2
Foo
Foo/Bar1
Foo/Bar2
 

The GNUstep implementation seems to have no specific ordering.

Joe Mattiello <joem>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by joem (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-08-04 CaS StatusNone Invalid
        Open/ClosedOpen Closed
    2009-08-04 CaS Item GroupBug Change Request

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code