[Bug 48251] Sorting directory entries

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=48251


Theodore Tso <tytso@mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |tytso@mit.edu
         Resolution|                            |INVALID




--- Comment #1 from Theodore Tso <tytso@mit.edu>  2012-10-03 16:29:50 ---
There is never a guarantee that directory entries are listed in the same order
that they are created.  If you are writing a program where you are making this
assumption --- don't.  It's something which has never been true, for any file
system.

With ext3 if the directory hashing feature is enabled (which it is by default),
the directory entries are returned in hash order.  This was needed so we could
meet POSIX requirements for how readdir() behaves in the face of telldir() and
seekdir(), as well as files being created while iterating through the directory
entries using readdir().  (The short version is once you use a tree, if you do
a node split due to a file being created, and where half of the directory
entries in the node are copied to a new leaf block, it still must be the case
that each directory entry which was created before starting the readdir() pass
must be returned once and only once.   In order to guarantee this, we traverse
the tree in hash order.)

If you disable the directory hashing feature, then the files will be returned
_roughly_ in creation order; however, once you start deleting directory
entries, new files can get inserted into the unallocated portion of the
directory, which means readdir() won't be returning the files in creation
order, even though previously it would appear to be returning files in creation
order before any files had been deleted.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.