Open Bug 527654 Opened 15 years ago Updated 2 years ago

implementing mbox fuse filesystem for (at least) attachment management

Categories

(Thunderbird :: OS Integration, enhancement)

Product:
Thunderbird
Component:
OS Integration
Platform:
x86
All
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: macmaN, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
Build Identifier: 

my primary platform is OS X and opening attachments means copy of attachment gets saved somewhere and then opened. this is cluttering and duplicating behavior, which could possibly be improved by implementing an mbox fuse filesystem. thunderbird could be user-configured to look for a directory where this filesystem is and if such configuration exists, open the attachment directly from this filesystem, replacing the lacking behavior mentioned above. if fuse access has not been configured, just fall back to existing behavior.

Reproducible: Always
Clicked from here the linked documentation is 401 as it requires auth. Looking up from google "mbox fuse filesystem" gives the same link vut without the 401.
Blocks: 402392
URL: https://sourceforge.net/apps/mediawik... → http://sourceforge.net/apps/mediawiki...
Status: UNCONFIRMED → NEW
Ever confirmed: true
IMHO this request should be made in the FUSE community not in the mozilla one. Also please bear in mind, that:
a) mbox is far from being easy to implement as a writable filesystem
b) treating signed/encrypted messages would require extensive use of metadata and access to (possibly many) password protected keys (for decryption) - quite difficult for a filesystem driver?

I suggest the following:

1) the file opened from mail client has to be decoded somewhere anyway - if you don't like your temporary directory being used because it is on slow harddrive, configure the temp dir to use tmpfs or similar (if it does exist on OS X).
If it isn't possible to change the temporary directory location in TB, file a bug for that.

3) you can detach the attachments - it would save you some space by the way, as it would not be encoded for safe mail transfer (which is up to 1.6 times the original size).
This bug doesn't block bug #402392. It may depend on it, but not block it - please remove that.
hi petr

a) i was thinking read-only for starters, just to accomplish a subset of goals. your point about w capability is probably correct.

b) encrypttion metadata could possibly be exported through some extension interface, no? i don't have encrypted e-mail coming in almost at all, so also an edge use case for me.

1) good thought for a temporary solution, although hdd speed is not the problem.

3) after attachment is detached and the file is possibly moved in filesystem, the link to the original e-mail is lost, right? i consider keeping this link intact important for business.
Petr,  bug #402392 is a meta, not an "implementing" bug. As such, this bug should block it.
(In reply to comment #5)
> hi petr
> 
> a) i was thinking read-only for starters, just to accomplish a subset of goals. your point about w capability is probably correct.
> 
> b) encrypttion metadata could possibly be exported through some extension
> interface, no? i don't have encrypted e-mail coming in almost at all, so also
> an edge use case for me.

Right, but the fs would have to be quite general - one encrypted message in an mbox would generally break usability.

> 3) after attachment is detached and the file is possibly moved in filesystem,
> the link to the original e-mail is lost, right? i consider keeping this link
> intact important for business.

Yes and I don't think it is reasonably possible to implement this inside mozilla, platform-independently on a general filesystem. In these cases one might be better off with things like Akonadi in KDE (or whatever it is called).
Or some fork of the maildir format.

However, thinking about this in general, you actually don't want to open attachment directly "inside-the-message" - it would be to easy to change it by chance and thus lose the original form of the message. A decent email client doesn't allow you to edit received/sent messages in place.
(In reply to comment #6)
> Petr,  bug #402392 is a meta, not an "implementing" bug. As such, this bug
> should block it.

Wayne, I prefer to see this (the dependence) the other way round. Implementing this bug doesn't unblock #402392 as that one deals with writing a reasonably extensible mailbox access layer. On the other hand, solving #402392 in such general way unblocks all the format-specific bugs (qmail, mboxfs, db...). That is assuming we want the general layer and not just a dozen of incompatible format-specific implementations.

Is there some manual on the bug dependence terminology in the mozilla dev-docs?
(In reply to comment #8)
> (In reply to comment #6)
> > Petr,  bug #402392 is a meta, not an "implementing" bug. As such, this bug
> > should block it.
> 
> Wayne, I prefer to see this (the dependence) the other way round. Implementing
> this bug doesn't unblock #402392 as that one deals with writing a reasonably
> extensible mailbox access layer. On the other hand, solving #402392 in such
> general way unblocks all the format-specific bugs (qmail, mboxfs, db...). That
> is assuming we want the general layer and not just a dozen of incompatible
> format-specific implementations.

That is what we want - it's the first thing that needs to happen before we implement any other thing. That's the way the core thunderbird engineering team wants it. If we go you way we'll end up having to maintain many not very used fetaures oursleves which has a cost.
 
> Is there some manual on the bug dependence terminology in the mozilla dev-docs?

Not that I know of.
(In reply to comment #9)
> (In reply to comment #8)
> > ... assuming we want the general layer and not just a dozen of incompatible
> > format-specific implementations.
> 
> That is what we want - it's the first thing that needs to happen before we
> implement any other thing. That's the way the core thunderbird engineering team
> wants it. If we go you way we'll end up having to maintain many not very used
> fetaures oursleves which has a cost.

OK, then this bug does not block #402392, rather it depends on it, right?
(In reply to comment #10)

> OK, then this bug does not block #402392, rather it depends on it, right?

Strcitly speaking yes.
No longer blocks: 402392
Depends on: 402392
May I add a partial workaround?

You can use IMAP, and have the mail server use the *maildir* format. Then keep it all in server directories. Now access those directories directly (e.g. via sshfs or having the mail server run on the local box). This should at least give you access to the separate mails as files.
Then all you’d have to implement, is a splitted-multipart view (that makes every mail file a directory of parts) in FUSE, passing everything else through as-is.
A small extension would make this pretty comfortable in Thunderbird too.

Of course having Thunderbird use maildir in the first place, would be better.
And adhering to the rule that “everything is a file (at least from the user’s p.o.v.” (you know… the Unix/Linux solution) would of course be best.
TB IMAP work is going on: bug 58308, bug 402392

Other than that, you're right, maildir FUSE implementation would be just as good for at least my purposes. I have already googled when I was looking around about this bug, unfortunately no solid works seem to have emerged so far.
Bleh, "TB maildir work", not "TB IMAP work"
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.