Martin Fick wrote: > > --- Krishna Srinivas <krishna@xxxxxxxxxxxxx> wrote: > > >> >> Correct, if machines running afrs are not time sync, >> >> it can cause problems. >> >> We were thinking of using parent's directories >> >> version as the file's createtime attribute. We >> >> increment the parent dir version first then >> >> create the file and apply parent's version as the >> >> file's createtime. >> >> Any thought on this? > > > > /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. > > 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. Gordan
