IMAPFS implementation

Filesystem specification

Body text is a representation of the file attributes. Each line contains one attribute. Here is the format:

-1	inode (unused; always -1)
100644	mode (in octal; contains file type & permissions)
1	nlink (unused; always 1)
500	uid
500	gid
0	rdev (don't know what this does)
10764	size (in bytes; should match size of attachment for regular files; should match length of target path for symlinks)
1	number of blocks (unused; always 1)
1181286957	accessed time (all times are in Unix time; i.e. seconds since 1970)
1181286957	modified time
1181286952	changed time

For regular files, it is an attachment with the content of the file. This may or may not be encoded in Base-64 by JavaMail depending on the type of data. If it is a plain text file, it is often not encoded, and stored directly in the email; as a result the last newlines / spaces of the file may be lost, because it is indistinguishable from the email's own formatting.
For symbolic links, it is a text part with the path of the target
For directories, it is an empty text part

Note: the IMAP server needs to support nested IMAP folders for subdirectories to work
Like files, directories also produce an email in the parent directory that contains its attributes and indicates that it is a directory
Root directory (/) attributes are stored in a canonical file in the filesystem. This is currently hard-coded as "/.ROOTATTR"

Root of filesystem is at some user-specified IMAP folder. All subdirectories use IMAP nested folders underneath that folder.

Because file contents and attributes are stored as parts of the same email message (which cannot be modified in-place for IMAP)

Any changes to the attributes (rename, change permissions, change ownership, change timestamps, etc.) require downloading and deleting the entire file and re-uploading it
This may be inefficient for large files

Licensed under GPLv2
Written in Java 1.5+
Uses the Sun JavaMail library (part of GlassFish, which is dual-licensed under the CDDL and GPLv2 w/ classpath exception)

There also exists a GNU JavaMail library. However, we do not use it because its IMAP store uses a single connection instead of a pool of multiple connections, which we need.

Unfortunately, this is very buggy and seems to not have been no longer developed for a long time

Open – the entire content is downloaded and saved to a temporary file
Read / write / etc. – performed on that temporary file
Fsync – if any writes have been made on the file, the original email is deleted and a new email is uploaded containing the new contents of the file (IMAP does not support editing messages online)
Flush – do nothing
Release – same as fsync above
Close – note that FUSE has no "close" operation; when files are closed, flush and/or release are called in weird ways that I do not understand. If you do, please help me

it is difficult to determine such information as disk usage and number of files in an IMAP folder structure
we could presumably store such information in a canonical file; but this file will have to be updated a lot