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