[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: remove - bug ???
From: |
Bob Proulx |
Subject: |
Re: remove - bug ??? |
Date: |
Wed, 22 Mar 2006 09:59:20 -0700 |
User-agent: |
Mutt/1.5.9i |
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