Hi again,

I know I'm making a lot of noise, but has the below fix been implemented 
in YAFFS' HEAD?

// Martin

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