Closed Bug 615545 Opened 14 years ago Closed 14 years ago

Compressing folders replaces symlinked mailboxes with local ones -- serious risk of discrepancy and divergence

Categories

(Thunderbird :: General, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: sombragris, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-MX; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-AR; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6

This is very simple to reproduce, but you need the following:

* A Windows (I'm using XP)/Gnu/Linux dual-boot system. The NTFS partition is writeable under GNU/Linux

* Thunderbird installed on both partitions.

* Mailboxes in the GNU/Linux setup are symlinks pointing to those located at the NTFS partition.

Well; in this setup, and running Thunderbird under GNU/Linux, compressing a folder causes that the replacement of the symlinked mailbox for a LOCAL, compressed one, without any warning or notice. The original mailbox, residing in a Windows NTFS partition, is intact.

This is potentially very serious: the user could further update her mailbox in the GNU/Linux session, getting new messages. However, upon booting on Windows, the messages are not there. One has to resort to manually copy messages from the divergence date (to "transitory" mailboxes), and other measures in order to recover data.

When compressing, Thunderbird should write into the symlinked mailbox file, not replacing the symlinked mailbox file with a local one.

Thanks for all the good work in Thunderbird.

Reproducible: Always

Steps to Reproduce:
1.Get a Thunderbird setup with a mailbox in a symlink
2.Compress the folder.
3.Surprise..!!!


Expected Results:  
Thunderbird should honor symlinked mailboxes.
> symlinked mailboxes

At which level the symlink for "mailboxes" do you define?

Following is prefs.js entries corresponds to "Local Directory:" at "Server Settings" of Tb's account definition.
Example of C:\MAIL-NEWS\Mail\<hostname> instead of <profile directory>\Mail\<hostname> on Win.
Tb's Local Directory: definition for mail.server.server6.hostname = mail.spymac.com.
> mail.server.server6.directory-rel=[ProfD]../../../MAIL-NEWS/Mail/mail.spymac.com
This is resolved like next.
> mail.server.server6.directory=C:\wada\MAIL-NEWS\Mail\mail.spymac.com
File path of mail folder file/directory for subfolders under this directory becomes like next. (Inbox example)
> C:\wada\MAIL-NEWS\Mail\mail.spymac.com\Inbox     (unix mbox for mail data)
> C:\wada\MAIL-NEWS\Mail\mail.spymac.com\Inbox.msf (mail summary file)
> C:\wada\MAIL-NEWS\Mail\mail.spymac.com\Inbox.sbd (directory for subolders)

Do you define symlink for this lowest file level file path of /<a directory or profile directory>/Mail/<hostname>/Inbox?
If so, as Tb's action on file named Inbox upon Compact is "copy active data in Inbox to real file named nstmp-N", "delete file named Inbox", and "rename nstmp-N to Inbox", symlink of /<a directory or profile directory>/Mail/<hostname>/Inbox is probably deleted and real file of Inbox is created.

Tb doesn't change /<a directory or profile directory>/Mail/<hostname> part once account is defined and "Local Directory:" setting is defined(or changed by you).
I guess symlink at /<a directory or profile directory> level or /<a directory or profile directory>/Mail/<hostname> level won't produce your problem.
My symlinks are defined at the "lowest" level you mention; i.e., for example, a symlink for the "Inbox" mbox file.

Raising the level of symlinking may be adequate as a workaround; I'll look into that. Thank you!

However, in any case, the problem I'm describing is, in my opinion, a serious issue, and not documented; and could potentially lead to data loss. If you have your Inbox mbox file in a symlink, it should stay that way after compressing. OR, at the very least, you should get a warning either at the program itself or its docs.
Symlinking individual files within a mailbox folder is an invitation for disaster, and it is not something really worth supporting. If you want to share files between different installations, you can change the profile location (or symlink it), and you can also change the storage location of the mail folder for individual accounts.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
"Symlinking individual files within a mailbox folder is an invitation for
disaster"... why? Back in time, it was a good workaround for setting Thunderbird in a dual-boot environment. It worked well... until I had to compress my Inbox, that is.

"it is not something really worth supporting" Really? As I said, it is used as a workaround in a dual boot environment. It may be a dirty hack, but it is used; and there is a risk of data loss when compressing folders in this situation. Is a data loss situation, in a dual-boot environment, really not worth supporting? This is strange, especially coming from an application that prizes itself on being cross-platform.

As you may see, I hardly agree with Joshua on the WONTFIX status.

However, I understand the reasons behind the WONTFIX. But at least a tiny mention in a knowledge base, documentation, or release note would be appreciated, and it would be a nice way of "fixing" this issue without changing a single line of code.

Thanks and best regards,


Eduardo Sánchez
Asunción, Paraguay, South America
I also disagree with the WONTFIX status.

I did not symlink individual files. I symlinked the whole ~/.thunderbird and I ran into the same problem when I restructured my partition layout.
I also have a multiboot environment, but no Windos. Only multiple Linux'es. And I have a shared big data partition. Because I don't want to share everything in /home, every Linux installation has its own /home. Only some directories (like ~/.thunderbird) are symlinked to the data partition.

One of the most important benefits of symlinks is to be able to change the location of files and only need to adjust the symlink. Then everything should work as before. I think that no application should ever sabotage that.
Update:
I have two things I would like to add.

1) Why I can't simply put my data back to the old location
Up to a few days ago, I hat two shared data partitions, /shared and /home/markus/hdd2 on two physical hdd's. .thunderbird was symlinked to hdd2/mozilla_thunderbird and hdd2 crashed. Forutunately, I had a backup that was only a few days old. With the system disk also being quite old (meaning: slow and likely to crash in the near future), I took the opportunity to buy a lagrer system disk that can hold all of my Linux'es, /shared, /home/markus/hdd2, and still have plenty of space left. So, the old location does not exist anymore. And I don't want to move /shared to /home/markus/hdd2, because it holds data from other users, too.
BTW: moving my Firefox profiles from /home/markus/hdd2/mozilla_firefox to /shared/home/markus/mozilla_firefox (and adjusting the .firefox symlink) did not cause any trouble. And all of my other applications also caused no trouble at all.

2) Using "Account Settings" -> "Server Settigs" -> "Local Directory" did _not_ help.
My workaround for now is an additional symlink /home/markus/hdd2 -> /shared/home/markus so Thunderbird finds its data at the seemingly old location.
After setting the "Local Directory" to /shared/home/markus, I searched the directory for occurences of /home/markus/hdd2 by using
find -type f | xargs fgrep -l /home/markus/hdd2
and there was an empty result. OK, I don't know if there are hidden occurences in the base64 encoded parts.
Anyway, although I have set the "Local Directory" to the new location, Thunderbird only works as long as the additional symlink mentioned above exists. When I delete it and start Thunderbird, it says my profile does not exist.
You need to log in before you can comment on or make changes to this bug.