All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.