gmail as a gigabyte of an external filesystem
Cuuuute! :) Could be even more interesting if combined with a suitable kind of encryption; I don't know how much I should trust Google, they are way too big to not be more than attractive "focus point" for "carpet-watching" people. The author is aware of this issue. Question for the crowd: How difficult it would be to write a suitable crypto engine as a plug-in module for FUSE itself? Then we could have support for encrypted files on any filesystem accessible through FUSE. ----------- http://www.boingboing.net/2004/08/29/turn_gmail_storage_i.html What to do with all that extra, network-based storage that comes with your Gmail account? If you're using Linux, you can turn it into a mountable filesystem with GmailFS. GmailFS provides a mountable Linux filesystem which uses your Gmail account as its storage medium. GmailFS is a Python application and uses the FUSE userland filesystem infrastructure to help provide the filesystem, and libgmail to communicate with Gmail. GmailFS supports most file operations such as read, write, open, close, stat, symlink, link, unlink, truncate and rename. This means that you can use all your favourite unix command line tools to operate on files stored on Gmail (e.g. cp, ls, mv, rm, ln, grep etc. etc.). Link (via Waxy) <http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html> posted by Cory Doctorow at 08:21:29 AM
On Sun, 29 Aug 2004, Thomas Shaddack wrote:
Question for the crowd: How difficult it would be to write a suitable crypto engine as a plug-in module for FUSE itself? Then we could have support for encrypted files on any filesystem accessible through FUSE.
----------- http://www.boingboing.net/2004/08/29/turn_gmail_storage_i.html
It seems that there is a solution Out There already, in the form of EncFS. See http://arg0.net/users/vgough/encfs.html Mount the GmailFS as eg. /mnt/gmail, and then mount encfs to eg. /mnt/gmailsec with /mnt/gmail as its root. Voila, problem solved! (At least theoretically. I didn't test it.) What are your thoughts on EncFS, please? Related note: Is there a way to encrypt a removable medium, eg. a CD or DVD disk, in a way that makes it readable under all major OSs (with the required add-ons installed), namely Linux, BSD, and Windows 98/2000/XP? The appeal (and a certain disadvantage) of EncFS is its file-oriented approach, making it easy to have a portable userspace decoding utility, for data access anywhere if you got the password.
Don't know anything about EncFS, but you could also use loopback encryption on top of gmailfs. Just make a large file in gmail fs, and make a filesystem in it via loopback virtual block device-in-a-file. Adam On Fri, Sep 03, 2004 at 04:44:58AM +0200, Thomas Shaddack wrote:
On Sun, 29 Aug 2004, Thomas Shaddack wrote:
Question for the crowd: How difficult it would be to write a suitable crypto engine as a plug-in module for FUSE itself? Then we could have support for encrypted files on any filesystem accessible through FUSE.
----------- http://www.boingboing.net/2004/08/29/turn_gmail_storage_i.html
It seems that there is a solution Out There already, in the form of EncFS. See http://arg0.net/users/vgough/encfs.html
Mount the GmailFS as eg. /mnt/gmail, and then mount encfs to eg. /mnt/gmailsec with /mnt/gmail as its root.
Voila, problem solved! (At least theoretically. I didn't test it.)
What are your thoughts on EncFS, please?
On Fri, 3 Sep 2004, Adam Back wrote:
Don't know anything about EncFS, but you could also use loopback encryption on top of gmailfs. Just make a large file in gmail fs, and make a filesystem in it via loopback virtual block device-in-a-file.
According to the shards of knowledge about GmailFS (gained on Slashdot), every file write sends the entire file to the Gmail mailbox. So this approach would be VERY taxing on the bandwidth. (Besides, even "free" resources should be conserved, whenever practical.) For GmailFS, we need a file-oriented approach, for which the EncFS one is perhaps the best of the few ones known to me. (A workaround could be to modify the loopback driver, so instead of one loop file one could use a directory with a suitable number of "clusters" of suitable size. Could be useful for the situations where we need a filesystem realized on a device allowing file access with coarse granularity, without easy random access to file offsets. But I am not sure if it is worth the hassle. (Sure is, just find the proper scenario.))
participants (2)
-
Adam Back -
Thomas Shaddack