<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d"><br>Jameson "Chema" Quinn wrote:
<br>> Does anyone know if it is possible for Sugar to support something like<br>> this? That is, if it there's any way - either file-system-native or<br>> through some strap-on - to safely hand a link to a process so that
<br>> (either magically or manually) it can replace the link with a local copy<br>> if needed, but it CANNOT modify the original file?<br><br></div>In the interest of simplicity, why not just use UNIX permissions and simple
<br>editor logic?<br><br>The activity's files are all read-only to non-root. Just read them into the<br>editor. If the user makes a change, save it as a new file, with appropriate<br>permissions.<br><br>- --Ben</blockquote>
<div><br>This is one option. The problem is that the activity could depend on having the right file names. So to do this, I think I'd have to make a copy of the directory structure filled with activity-owned symbolic links, to be able to delete and overwrite with the local copy. Some activities would probably break even then, too, because of the difference between symbolic and hard links.
<br><br>Obviously, whatever I do in this direction is going to need special logic in the activity isolation and the datastore, to allow Develop to get at multiple files in funny places in the datastore, and to store in the datastore some kind of 'key' to resume work on these files later.
<br><br>In other words, this is a tough problem and I'll probably be bugging the list dozens of times before all's done. I understand that this first issue has workarounds, but if there's some way to get direct COWLB power in JFFS2, that would help keep things simpler.
<br><br>Jameson<br></div></div><br>