Something that's been rattling around in my mind for the past week is the need to integrate removable storage into the Bitfrost and Journal systems. Obviously we don't want to automatically include anything ever plugged into the system into the backup/Journal system, but if I share a file off my USB key or USB hard-drive with someone then it needs to be made available to them at least for the current session, but potentially permanently.

So how does it happen? Let's consider the simplest scenario, access to a USB key with files on it. We open the Journal, choose "devices" and add access to the USB device to the current space. It shows up as a sub-directory in the home directory named "USB Key" or "Key Volume Name" in the current activity's file namespace.

Now, by default we would mount the USB as a read-write no-overlay directory, so that saving files would overwrite the contents of the file-system. That is, the directory would just look normal as far as the activities/applications are concerned.

Alternately we could allow for specifying loading the file-system as a versioned file-system overlay iff the file-system already has the versioning meta-data available (or it is blank). In other words we would mount a read-only/read-write image on the USB key and store all new writes to the (new) read-write directories we create as overlays on the USB key.

If the user wants to move a file onto the USB key, they open the Journal, choose the "local activity files" view, drag the file into the USB directory. If the key is in versioned mode the file gets put into the read/write overlay. If the key is in non-versioned mode the file simply gets written into the namespace.

If any of the users would like to transfer a file into the (shared) Journal, they need merely copy it into the "regular" (non-usb key) directory in the current namespace.

On sharing, the sharing user should be able to specify (or more reliably, default to the condition for non-versioned storage) that the USB key be shared as read-only. If the user wants to share the USB key read-write, they would have to explicitly allow that for any non-versioned storage.

The removable directory should show up on sharing as a transparent proxy for the mounted remote directory. If you want to simply load a file into an application, you can just File|Open it, if you want to copy it to your Journal, open the Journal and copy within the "local" space from the (remote) mount into the normal (non-shared) area. What mechanism should be used for the file access though?

We probably want the sharing of a mountable resource to be explicit. That is, if I mount a USB key to drag a file into the shared "project", I should have to explicitly then share the mount. That prevents problems with network shares and similar situations. I can load the mount, copy over files and not leak any information from the rest of the key without explicitly specifying that the people in my activity should be allowed access.

Same basic mechanism should work for network shares (NFS/SMB/SFTP/etceteras) as for the USB key. Probably want to have the share include a standard encrypted-share certificate, with the session key for the share being required to access the share (same as with any other Journaled resource).