patchThe GNU Hurd - Patches: patch #1839, Many small fixes in dir-rename.c...

 
 

You are not allowed to post comments on this tracker with your current authentification level.

patch #1839: Many small fixes in dir-rename.c and dir-renamed.c

Submitted by:  Ognyan Kulev <ogi>
Submitted on:  Mon 18 Aug 2003 01:38:39 PM UTC  
 
Category: libdiskfsPriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: None
Wiki-like text discussion box: 

Sat 19 Jul 2008 12:45:00 AM UTC, comment #2:

What a mess, some of the fixes have independently found again.

dir-renamed.c:

A lot of things that maybe make sense, a closer look is needed,
but Ogi hasn't provided explanations.

dir-rename.c:

Now really serialize directory renaming with RENAMEDIRLOCK.

I don't understand that part. In the debian report, Ogi says

`if renamedirlock is held by somebody else, then no
serialization will occur.'

But if renamedirlock is held by somebody else, the code
precisely takes the lock and starts over....

Now, one flaw which may happen is if you have in parallel

mkdir blip
mv blip blop
rmdir blip
touch blip
or whatever that disturbs blip and makes diskfs_lookkup() fail
or not be a directory any more, then we don't free the mutex...

When renaming directory, don't diskfs_node_update and
diskfs_file_update because dir-renamed.c::diskfs_rename_dir already
do it.

possibly still useful, I haven't investigated.

When TONAME is .. of filesystem's root, not only set ERR to
EINVAL, but return this error.

useless: it's precisely handled just below.

When EXCL is set and target exist, unlock things properly.

useless for the same reason.

When FROMNAME is regular file and TONAME is directory, unlock TNP
before returning.
When maximum link count of FNP is reached and TNP is not NULL, unlock
TNP before returning.

have been commited already.

When updating FNP after incrementing its link count, call
diskfs_node_update only if diskfs_synchronous.
After TONAME enters TDP, call diskfs_file_update instead of
diskfs_node_update.

I haven't investigated.

Samuel Thibault <sthibaul>
Project Member
Thu 19 Jan 2006 01:28:53 PM UTC, comment #1:

This patch needs breakup into individual parts, and explanations for them (and test cases for errors it fixes, if possible).

Discussion is here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190732;msg=147

Alfred M. Szmidt:
What bug did this patch fix exactly? Do you have any test cases for this?

Ognyan Kulev:
Many small bugs are fixed. Most of the sentences in the changelog entry are separate fixes that are not related to the other changelog entries. If it's needed, I can make more detailed explanation about each sentence.

Michael Banck <mbanck>
Mon 18 Aug 2003 01:38:39 PM UTC, original submission:

Other information about this patch can be found in http://bugs.debian.org/190732

Ognyan Kulev <ogi>
Project Member

 

Attached Files
file #7059:  dir-renamed.5.patch added by ogi (10kB - application/octet-stream - The patch is re-uploaded, but &lt; -> "<", etc.)
file #6051:  patch_item_1839.patch added by ogi (11kB - text/plain - patch item 1839)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by sthibaul (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 06 Mar 2004 04:33:37 PM UTCogiAttached File-=>Added dir-renamed.5.patch, #2856

    Back to the top


    Powered by Savane 3.1-cleanup