>>I know I'm making a lot of noise, but has the below fix been implemented
>>in YAFFS' HEAD?
> This is not yet fixed.
>
> I hope to do something about this during this week.
>
> I have though about it more and the "shadowing" method is still the best,
> IMHO.
Oki! :o)
>>>I have investigated this and figured out a fix which I will code and test
>>>in the next few days.
>>>
>>>I considered a few approaches, but the mechanism I have settled on uses a
>>>"shadowing" field.
>>>
>>>The code went like this:
>>>
>>> if (newname exists)
>>> {
>>> unlink(newname);
>>> }
>>> rename(oldname,newname)
>>>
>>>The problem Sergei discovered was that the power could be lost between
>>>the unlink and the rename, causing the file system to end up with no file
>>>called newname.
>>>
>>>We cannot just reverse the order because that could leave us with two
>>>names for different files -- bad!
>>>
>>>The new code will go like this
>>>
>>> if (newname exists)
>>> {
>>> rename_with_shadow(oldname,newname);
>>> // Point A
>>> unlink(newname);
>>> // Point B
>>> }
>>> rename(oldname,newname)
>>>
>>>A shadowing rename is like its non-shadowing brother except that it also
>>>stores the object Id of the object that it "shadows". The semantics of
>>>scanning a shadowing objectheader are different. If the shadowed object
>>>exists (ie power lost at point A) then we unlink it.
>>>
>>>Essentially the shadowing gives us a way of determining priority between
>>>two like-named objects.
>>>
>>>Why do we rename without the shadow afterwards? This is done so that we
>>>remove the shadow after it is no longer needed. If this was not done we
>>>would potentially have a shadow hanging around that would cause future
>>>files with the same object Id to get deleted.
(text/plain)