linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Teoh <htmldeveloper@gmail.com>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: Peter Teoh <htmldeveloper@gmail.com>,
	linux-fsdevel@vger.kernel.org, matthew@wil.cx
Subject: Re: "Write once only but read many" filesystem
Date: Wed, 26 Mar 2008 10:27:38 +0800	[thread overview]
Message-ID: <47E9B49A.30902@gmail.com> (raw)
In-Reply-To: <OF868FD1D4.5F293C4F-ON88257417.00637846-88257417.0065D1C8@us.ibm.com>

Bryan Henderson wrote:
>>> other times you talk about a filesystem that can be updated, ...
>>>       
>> NO updating is possible.
>>     
>
> I'm still not convinced you mean that, because the example you give is 
> specifically of a file that becomes immutable after some writing to it. 
> How about creating a new file?
Yes - always allowed.  

>   That is a filesystem update.  Do you want 
> to allow that?  How about directory modifications, such as rename and 
> unlink?
>   
Creating directories - always allowed.   Modification - rename/unlink 
etc will be disallowed.

> Yeah, that's what the bad guy will do.  So you haven't prevented someone 
> from undetectably modifying previously written data.
>
>   
This is the only difference between the current discussion, and the 
hardware WORM storage solution u mentioned in the previous email, due to 
it software vs hardware implementation aspect.   I have also found this:

ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/87/1177/CS-TR-87-1177.pdf

Well, I would like to thank you and Matthew for the discussion (I think 
using the printer is not advisable - the output is not really so 
immutable after all - JUST reprint the modified content will do.   
Similarly for WORM storage medium - just write into another CD.)

U agree with me?.   Sorry for the rubbish talk :-).

Anyway, I shall attempt to write some proof-of-concept patches to try 
out the idea.   I may fail.

Thanks.

  reply	other threads:[~2008-03-26  2:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-24  6:45 "Write once only but read many" filesystem Peter Teoh
2008-03-24 16:56 ` Bryan Henderson
2008-03-25  0:47   ` Peter Teoh
2008-03-25 15:22     ` Matthew Wilcox
2008-03-25 18:42       ` Bryan Henderson
2008-03-25 18:32     ` Bryan Henderson
2008-03-26  2:27       ` Peter Teoh [this message]
2008-03-26 16:49         ` Bryan Henderson
  -- strict thread matches above, loose matches on Subject: below --
2008-03-14 16:17 filesystem differentiation Peter Teoh
2008-03-14 23:24 ` Andreas Dilger
2008-03-22  4:39   ` "Write once only but read many" filesystem Peter Teoh
     [not found]     ` <20080322102331.GA19347@logfs.org>
     [not found]       ` <804dabb00803220752h670757d8o9c1b7fa3696467bc@mail.gmail.com>
     [not found]         ` <20080322150626.GB19347@logfs.org>
2008-03-22 15:55           ` Peter Teoh
2008-03-22 16:59             ` Jörn Engel
2008-03-24  4:49               ` Scott Lovenberg
2008-03-24  6:35                 ` Peter Teoh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47E9B49A.30902@gmail.com \
    --to=htmldeveloper@gmail.com \
    --cc=hbryan@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=matthew@wil.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).