<br><br><div class="gmail_quote">On Fri, May 9, 2008 at 6:43 PM, 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><div></div><div class="Wj3C7c">> 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></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></blockquote></div><br>Let me be a little clearer still about what I am envisioning. I do not imagine that, except in rare cases (restore after total data loss) the journal would ever scan external/network storage for an absent file, or explicitly import one or more files (as distinct from opening them or otherwise doing something meaningful with them, using a traditional tree/folder view). The journal index would know exactly where things were, but only if it put them there itself, or had used them there itself. It would then keep track of whether the containing volume/resource was available and show the links as broken/real on that basis. If the file had been deleted foreignly, it might mistakenly show as available but turn out to be unavailable when clicked on.<br>
<br>This model has several advantages. It does not require any scanning on mount; it does not add files to the journal if they have never been used; and its behaviour is generally understandable and predictable. If I am reading c_scott's link above correctly, it is not precisely what was on his mind, but it is supported by the same capacities of olpcfs, with the addition of an index by storage volume and some metadata (indexed only if you need to search it) for external path(s).<br>
<br>A couple of UI points:<br>- broken links could be filtered out by default in most views, but it would be a simple boolean switch (checkbox or the sugar equivalent) in the interface to show them.<br><br>-If UID can hide in the metadata, which, if I understand, is preserved as part of the file even on foreign (unix-only?) filesystems (wow!), I do not see any compelling reason for it to be in the filename. Locally-stored files could have their real filenames, with 2 random characters at a time added in case of collisions; for external storage, collisions could simply be forbidden, and you could rename or choose a different directory.<br>
<br>-some file formats already include a compatible metadata spec - for instance, an MP3 file already specifies artist. a by-format plugin api to keep the olpcfs metadata in sync with this metadata would be a nice future feature.<br>
<br>