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.<br>
<br><div class="gmail_quote">On Fri, May 9, 2008 at 11:43 AM, C. Scott Ananian <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, May 9, 2008 at 2:26 PM, Joshua N Pritikin <<a href="mailto:jpritikin@pobox.com">jpritikin@pobox.com</a>> wrote:<br>
</div><div class="Ih2E3d">> On Fri, May 09, 2008 at 12:10:07PM -0600, Jameson Chema Quinn wrote:<br>
>> To be more clear about this use case: I think that there should definitely<br>
>> be a way for the onboard datastore to store the metadata for an absent file,<br>
>> with hints about what place(s) to find that file (networked backup, sd<br>
>> cards, usb devices) and how to recognize it when you do. This should include<br>
>> the possibility for offloading old intermediate versions. Then, even when<br>
>> you do not have access to the backup storage, you can see what you are<br>
>> missing. This makes the result of suddenly yanking the SD card out more<br>
>> well-defined (assuming no filesystem corruption), and means you do not ever<br>
>> have to merge/separate two indexes (there is just one index).<br>
><br>
> I was surprised to read this. My opinion is that the index should only<br>
> include files which are available on local storage. Otherwise the index<br>
> can fill up with broken links, and it will be difficult to explain why<br>
> the broken links don't work. Access to backups is a good idea, but not<br>
> via such a by-default mechanism.<br>
<br>
</div><a href="http://wiki.laptop.org/go/Olpcfs#Absent_content_and_merging_remote_stores" target="_blank">http://wiki.laptop.org/go/Olpcfs#Absent_content_and_merging_remote_stores</a><br>
 --scott<br>
<font color="#888888"><br>
--<br>
 ( <a href="http://cscott.net/" target="_blank">http://cscott.net/</a> )<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>"Always do right," said Mark Twain. "This will gratify some people and astonish the rest."