linux-kernel - Re: Versioning file system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4678395B.4010805@redhat.com>
Date:	Tue, 19 Jun 2007 16:15:23 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Jack Stone <jack@...keye.stone.uk.eu.org>
CC:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
	"H. Peter Anvin" <hpa@...or.com>, alan <alan@...eserver.org>
Subject: Re: Versioning file system

Jack Stone wrote:
> Chris Snook wrote:
>> Jack Stone wrote:
>>> The idea was that if you did an ls you would get the latest version of
>>> the file without the :revision_num. The only visible version would be
>>> the latest version, i.e. the current system would not change. The idea
>>> was that it would only show earlier versions if they were specifically
>>> requested with a :revision_num suffix. In that case the
>>> filesystem/kernel would need to recognise the suffix and return the
>>> earlier version of the file.
>>>
>>> The only userspace it would break is files with :num in their name, as I
>>> haven't seen any files like that I don't think its too big a problem but
>>> the way of specifiying revisions could be changed.
>>>
>>> Jack
>> I have one right now:
>>
>> $ ls /tmp/ksocket-csnook/kdeinit*
>> /tmp/ksocket-csnook/kdeinit__0  /tmp/ksocket-csnook/kdeinit-:0
>>
>> Note, I did not pass any special arguments to ls to make it pull up that
>> file. You'd have to modify ls to make it do that.  You'd also need to
>> modify everything else out there.  There are decades of programs out
>> there that would behave differently with the interface you propose.
>>
>> The more fundamental problem with your proposed interface is that it
>> treats a filesystem like an opaque server, instead of a transparent data
>> structure.  You want files to be completely invisible to applications
>> that don't know about it, unless the user requests it.  Unfortunately,
>> it doesn't work that way. Applications ask for a directory listing, and
>> will open the requested file if and only if the filename in question
>> appears in that listing.  If you want to use this opaque server model,
>> you'd be better served putting it in some parallel file system (say,
>> /backup) that won't interfere with naive applications accessing the
>> mundane data.  Personally, I like your idea of putting the older
>> versions in the same directory hierarchy, but I think you'd have to use
>> .foo hidden directories to do it right.
> 
> The whole idea of the file system is that it wouldn't return the file in
> the file listing. The user would have to know that the file system was
> versioning to access the older versions as they would explicitly have to
> request them.
> 
> Jack
> 

Okay, so now you have to modify ls, cp, tar, and thousands of other applications 
to be aware of the versioning, otherwise you can't use it.

Please don't get hung up on the interface.  This is a really cool feature that 
will require some serious engineering work to make it work right.  There's no 
need to reinvent hidden files as well, since we already have a decades-old 
standard for that.

	-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/