Messages in this thread | | | Date | Fri, 19 Mar 2004 09:11:48 +0000 | From | Jamie Lokier <> | Subject | Re: unionfs |
| |
Jörn Engel wrote: > And version control is something I actually want to be done inside the > kernel, at least to some degree. People already use kernel support, > although it sucks (cp -lr anyone?). Looks like the alternatives suck > even more, so your point is void.
Fwiw, I much prefer your COW hard links to something where I have to mount a new filesystem every time I "copy" a tree, and have to redo those mounts each time I reboot, have a big ugly mess in "df" output, what "du" get confused, and "rsync" has no hope of dealing with them sensibly.
I also don't mind if copying isn't implemented in the kernel. I'm ok with programs reporting an error that they couldn't write to a file because it was linked readonly. At least that removes the danger of accidental overwriting, and I can either fix it by hand or use an LD_PRELOAD library which detects that error code from open() and copies the file.
Even if vi and Emacs, which make it temptingly easy to ignore normal read-only protection, were changed to be aware of and bypass the read-only link attribute, they'd do the right thing: the attribute expresses the _intent_ that removing it should always be done by copying the file, whereas with hard links that intent isn't clear. (Emacs has backup-by-copying-when-linked, but that isn't too helpful because sometimes you want writing to a linked file to change both places).
So my vote is for the very simple COW hard link attribute, and leave the rest to userspace.
Thanks! -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |