[PVFS2-developers] Removing of a directory

[Phil Carns]

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 at beowulf-underground.org
>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>>
>>
>> _______________________________________________
>> PVFS2-developers mailing list
>> PVFS2-developers at beowulf-underground.org
>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>>
> 
> _______________________________________________
> PVFS2-developers mailing list
> PVFS2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers