And of course now I read Jim's note with the subject "Remove Utility- need guidance" which addresses the "Circular directory structure" problem. Just ignore my message. Sorry for the noise.
Bob Bob Proulx wrote: > 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
