On Monday 25 July 2005 19:51, Martin Egholm Nielsen wrote:
> Hi again,
>
> 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.


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