--- Gordan Bobic <gordan@xxxxxxxxxx> wrote:
> Martin Fick wrote:
> > /dir1/dir2/file
> >
> > file and dir2 are deleted
> > dir2 is re-added
> > file is re-added and dir2 version is now the
> > same as it was before it was deleted.
> >
> > Same problem as before but one level higher.
> > You would need to version all the way to the
> > root, "/", for this to work, wouldn't you?
>
> No. You just need to treat directories the same as
> any other file. When a create/delete operation
> happens, the directory version gets bumped up.
> So removing and creating a subdirectory (or a file)
> would result in the created file/directory having a
> major version 2 versions higher than the
> previous instance.
Think parent directory, not subdirectory. If the
parent directory of the file and the file itself
are deleted and recreated you may end up with
the same versions of both the parent directory and
file!
Original creation process and versioning:
/
v1
/dir1/
v2 v1
/dir1/dir2/
v2 v2 v1
/dir1/dir2/file
v2 v2 v2 v1
Mirror goes off-line with version #s of dir2 and file
as: v2/v1.
-> file deleted
/dir1/dir2/
v2 v2 v3
-> dir2 deleted
/dir1/
v2 v3
-> dir2 recreated
/dir1/dir2/
v2 v4 v1
-> file recreated
/dir1/dir2/file
v2 v4 v2 v1
Uh oh, now if I look just at the version #s of dir2
and file I get: v2/v1 these are the same as they
were above when our mirror went off-line, the file
looks like it is the same when in fact both it and
its parent directory have been recreated!
However, if we were looking at the versions all the
way to the root, when the mirror went off-line we
would have had: /v2/v2/v2/v1 and now we have:
/v2/v4/v2/v1. There is a chance that we are
talking about different files now. Of course, the
problem I see now is that the files could in fact
have been the same even though the version number is
different with this scheme! Since the only version
# that is different is that of dir1 (v4), this could
have been caused by simply adding two new files to
that directory!
We now have the reverse problem, possible resyncing
when not needed. This means that possibly every
single subdirectory/file of a directory needs to be
resynced. Yikes, this problem would also be
prevalent (although less intense) even when just
using the parent's version # wouldn't it? Every time
a directory is reversioned, all the files in it are
now reversioned?
> > > Directory moves could create a similar problem:
> > >
> > > /dir1/dir2/file
> > > /dir1/dir3/file
> > >
> > > /file and dir2 deleted.
> > > dir3 moved to dir2 and happened to match file
> > > and dir2 version #s.
> > >
> > > but I think that versioning to the root would
> > > again solve this?
>
> You don't need versioning up to the root, you just
> have to treat moves the same way as copy+delete from
> the versioning point of view. This doesn't mean you
> actually have to copy+delete - you just have to
> update the metadata as if you did.
I wasn't implying that a move was a special case,
rather that by moving the parent directory to a file
you could end up with the same problem that I describe
above where a file is a completely different file than
on the mirror, but both the file and parent
directory's version #s are the same.
-Martin
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
