>>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.