[linux-elitists] Update--distribution for your mother?
Tue Aug 19 01:55:29 PDT 2003
Geoff Lane wrote:
> On Mon, Aug 18, 2003 at 11:46:35AM -0700, Greg KH wrote:
>>On Sun, Aug 17, 2003 at 08:21:52PM +0100, Geoff Lane wrote:
>>>The Linux kernel is an excellent foundation, but from the filesystem up to
>>>the GUI everything must change. For example, this portable I'm typing on
>>>has a 60Gb hard disk. I don't work on AV projects so that 60Gb will last me
>>>80 years at the rate I generate new data before I would be forced to erase
>>>any old data. Yet no filesystem provided with popular Linux distros can
>>>make use of this to provide rollback of files or entire filesystems
>>>following user mistakes. "delete it and it's gone forever" is a lousy
>>>design principle for a device to be used by the casual user. A trash can is
>>>not a solution because it asks the casual user to understand how all the
>>>cogs, belts and chains are related.
>>Many people are eagerly awaiting the patches to the existing filesystem
>>code from you to implement these "much needed" new features.
> Sadly, I very much doubt that any existing filesystem designed for linux
> could be patched to provide any kind of efficient roll back facility. In
> fact, I doubt that any such filesystem could be properly posix complient.
> I'll be able to say for sure once I've finished Linux File Systems by Moshe
> Bar. Certainly forcing rollback into the current VFS may be tricky.
hmm.. yeah well, you might want to consider additional sources of
information about this subject beside books from that auther ;-)
Anyways, here's the thing -
Sure, if your file system is laid out in something like the way things
are done in Windows - binaries, user data and configuration files all
lying around in random places and both system and user configuration
data is stored in oen huge binary database file, then maybe the only way
to make sense of all of this is to resort to VFS layer level of support
for what you want.
But let's take a look at a run of the mill LSB system for a moment. Most
of the data (binaries, system configuration, etc.) is stored seperate
from "user land". From your "delete it and it's gove forever" refernce I
assume you are refering to user data files: stuff like documents and
This is a much more limited "file space" to protect and you don't really
need a new file system to introduce versioning information for it.
Just create a shared library that hijacks the open() and friends file
related system calls (for starters you can start with just unlink()) and
override them with something that keeps a copy of the old version around
prior to change. You then can apply this to specific programs or
specific users via use of LD_PRELOAD.
I know it's not 100% problem free (what to do with SUID binaries, for
example?) but I think you can get something that covers much more then
you think of your problem space using this approach and solves your
needs as I understand them quite well.
No need for new sophisticated (and bloated and buggy) kernel code at all :-)
<rant about some propritery and dying Unix variant ignored>
> Those of us who have used versioning filesystems (popular 25 odd years ago)
> know how useful they can be; equally we know the problems they present when
> used with uncooperative applications (such as those that do not, or cannot,
> use modify in place policies when updating files.)
I think "popular 25 odd years ago" is a very telling remark here.
More information about the linux-elitists