[lkml]   [2004]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: readdir loses renamed files
On 25.10.2004, at 15:37, Theodore Ts'o wrote:

> This is not a bug; the POSIX specification explicitly allows this
> behavior. If a filename is renamed during a readdir() session of a
> directory, it is undefined where that neither, either, or both of the
> new and old filenames will be returned.

BTW. Would be nice if this was mentioned in readdir(3) manual page.
UNIX98 specs also didn't mention rename specifically, and I don't know
of other freely available specs.

> And that's because there's no good way to do this without trashing the
> performance of the system, especially when most applications don't
> care. (Do you really want your entire system running significantly
> slower, penalizing all other applications on your system, just because
> of one stupid/badly-written application?) In order to do this, the
> kernel would have to atomically snapshot the directory --- even one
> which might be several megabytes in length, and store a copy of it in
> memory, while the application calls readdir(). Several processes
> could perform a denial-of-service attack by starting to call
> readdir(), and then stopping. This would end up locking up huge
> amounts of non-pageable system memory, and cause the system to come
> down in a hurry.

That would be a generic kernel solution for it, but it's not what I'm

Only thing needed not to lose the files would be that renamed files
appeared always at the end of the readdir() list, or at the same
location where the original file was. But apparently that's not how
filesystems nowadays implement it, and probably not very simple to
change to work that way.
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 14:07    [W:0.057 / U:6.340 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site