On Dec 16, 2005, at 1:57 PM, Phil Carns wrote:
That is a good point. As it turns out there is a cheap way to add
this extra check. sys-rename has a bit of code that looks like
this (which was part of a fix to some rename bugs I ran into a
while back):
if(attr->objtype == PVFS_TYPE_DIRECTORY && attr-
>u.dir.dirent_count != 0)
{
js_p->error_code = -PVFS_ENOTEMPTY;
return(1);
}
I think remove could do the same thing. sys-remove already
retrieve the attributes, so there is no extra cost involved in
checking the dirent_count on the client side before proceeding.
Hi Phil,
It looks like the directory entry gets removed before we actually get
the attributes of the object. This prevents us from just checking
the attrs right away before the rmdirent. I think I can add the
check before doing the actual remove and after getting the attrs, but
I wasn't sure that's exactly what you meant. The order of operations
for a remove on a non-empty directory are:
1. rmdirent(object name,parent handle) => object handle
2. getattr(object handle) => attr
3. remove(object handle) => ENOTEMPTY
4. crdirent(object_handle)
If I understand things correctly, your proposal was to put the check
right after 2. This would prevent us from doing remove, but it would
still be necessary to do the crdirent. Is that right?
-sam
There isn't any way to 100% protect against race conditions if
directory renames/removals are driven from the client, but this
check would help a lot.
-Phil
Julian Martin Kunkel wrote:
Hi,
I have a question, if a client wants to remove a handle first the
directory entry is removed and then the client verifies if a
directory is going to be removed.
If a non empty directory is going to be removed the client just
creates the directory entry again for the parent directory,
because it is not allowed to remove a non emtpy directory.
Ok, but what happens with a filled directory if a client somehow
breaks while trying to remove ? If it breaks after removing the
dirent and before recreating the dirent, will the whole non-empty
directory be lost ? Wouldn't it be better to first verify that the
directory is empty ? I understand that after one client has
verified the directory to remove is empty another client might
create some files. So I think it would be better to verify the
emptiness twice. Directories which already have some entries could
be never messed up this way.
Or is there already a cool mechanism I did not realize to
circumvent that problem ?
Thanks for your reply.
Have a nice day,
Julian
_______________________________________________
PVFS2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
PVFS2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
PVFS2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
