There was a long delay because the mailing list was offline for several days.
Vineet Chadha wrote: > Modern operating system put the in-core inode into free list and > sometimes re-allocates inode immediately to NEXT creation of file > system object. That may be true. But it has nothing to do with user space applications such as the rm command. The kernel's filesystem does what it does and the application space commands use the provided kernel interface. > remove UTILITY heavily works on assumption that > directory-to-be-deleted is of single thread and not being modified > by other user or process. That is correct. There are no plans to change this. However much work has been done to make directory traversion as robust as possible, even in the presence of very deep directory hierarchies. > I confirmed this phenomenon ( though not conistently ) through > running two scripts (one creating 10000 dir hierachy and other > deleting it). There is no expectation that you can remove a directory tree in one process while another process is adding files to that same tree. > I think remove should be modified for concurrent user access to > directory. If you need two or more processes to coordinate on directory operations, such as creating a directory tree and deleting a directory tree, then you should use a semaphore to coordinate those processes. Or the traditional method is to have a single process operate as a daemon to perform all of the critical sections and therefore obviate the need for a semaphore entirely. Bob _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
