Ahh, you are right. I didn't realize that the attributes weren't read
until after removing the directory entry. With that being the case it
would have to come after step 2) as you say, although that isn't as
helpful as if we had the information earlier.
-Phil
Sam Lang wrote:
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
PVFS2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
PVFS2-developers mailing list
PVFS2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
PVFS2-developers mailing list
PVFS2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
PVFS2-developers mailing list
PVFS2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
