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.
(text/plain)