very simple datastore reimplementation

[Carol Lerche]

The notion of keeping track of off-line copies in an online journal is not
new.  In the olden days of small disks, many archival systems existed that
put old files onto archive tapes.    They did keep track of the location of
the archived file, and some of them prompted the operator (yes, I am
describing old mainframe systems) to mount the archive tape so that the file
could be restored to attached storage.  This was a convenient and natural
feature, making off-line storage much easier to use for non-technical
types.  These systems also kept track of deliberate storage to a tape, and
allowed a user to list tapes and their content that they owned/had access
to.  The requirement was that the tapes so managed be "checked in" to the
archival system.  I would suggest that you consider a similar scheme.
Choosing the default state ("checked in on mount" or "not checked in on
mount") would be something to think about, and possibly SD and USB devices
would have different defaults.

On Fri, May 9, 2008 at 11:43 AM, C. Scott Ananian <cscott at laptop.org> wrote:

> On Fri, May 9, 2008 at 2:26 PM, Joshua N Pritikin <jpritikin at pobox.com>
> wrote:
> > On Fri, May 09, 2008 at 12:10:07PM -0600, Jameson Chema Quinn wrote:
> >> To be more clear about this use case: I think that there should
> definitely
> >> be a way for the onboard datastore to store the metadata for an absent
> file,
> >> with hints about what place(s) to find that file (networked backup, sd
> >> cards, usb devices) and how to recognize it when you do. This should
> include
> >> the possibility for offloading old intermediate versions. Then, even
> when
> >> you do not have access to the backup storage, you can see what you are
> >> missing. This makes the result of suddenly yanking the SD card out more
> >> well-defined (assuming no filesystem corruption), and means you do not
> ever
> >> have to merge/separate two indexes (there is just one index).
> >
> > I was surprised to read this. My opinion is that the index should only
> > include files which are available on local storage. Otherwise the index
> > can fill up with broken links, and it will be difficult to explain why
> > the broken links don't work. Access to backups is a good idea, but not
> > via such a by-default mechanism.
>
> http://wiki.laptop.org/go/Olpcfs#Absent_content_and_merging_remote_stores
>  --scott
>
> --
>  ( http://cscott.net/ )
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



-- 
"Always do right," said Mark Twain. "This will gratify some people and
astonish the rest."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080509/8b87faa8/attachment.html>