Follow-up Comment #2, patch #1839 (project hurd):
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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/patch/?1839>
_______________________________________________
Message posté via/par Savannah
http://savannah.gnu.org/
