* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > perhaps having a new 'immutable hardlink' feature in the Linux VFS
> > would help? I.e. a hardlink that can only be readonly followed, and
> > can be removed, but cannot be chmod-ed to a writeable hardlink. That i
> > think would be a large enough barrier for editors/build-tools not to
> > play the tricks they already do that makes 'readonly' files virtually
> > meaningless.
>
> immutable hardlinks have the following advantage: a hardlink by design
> hides the information where the link comes from. So even if an editor
> wanted to play stupid games and override the immutability - it doesnt
> know where the DB object is. (sure, it could find it if it wants to,
> but that needs real messing around - editors wont do _that_)
so the only sensible thing the editor/tool can do when it wants to
change the file is precisely what we want: it will copy the hardlinked
files's contents to a new file, and will replace the old file with the
new file - a copy on write. No accidental corruption of the DB's
contents.
(another in-kernel VFS solution would be to enforce that the files's
name always matches the sha1 hash. So if someone edits a DB object it
will automatically change its name. But this is complex, probably cannot
be done atomically, and brings up other problems as well.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
