446437 - hardlink (on the filesystem) to the mail folder is broken after "Folder">>Compact

Status: RESOLVED WONTFIX

(MailNews Core :: Database, defect)

Description

[M.a.n.chen]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080404 Iceweasel/2.0.0.14 (Debian-2.0.0.14-2)
Build Identifier: Icedove version 2.0.0.14 (20080509)

Hardlinks are created to mailfolders. ("Inbox" etc.). After pressing "compact" (means "compress"), there are 2 files on the file system. One is the old hardlink, the other "the new compressed" file, wearing the same name. Thunderbird works fine, but other mail clients have the old file after compressing.
Potential solution:
Most probably after pressing "compact" the folder is marked as "rw", then copied to another temp file, and deleted, followed by renaming the temp file. This would make 2 files. And for the file system the new compressed file is another one, as the original one. 
My proposal for a solution is: The file to compress open RW, then compressing to another temp file, and after, without closing the original file, rewriting the data an -if neccessary- changing the size. If i am totally wrong- sorry for smart-****.

Reproducible: Always

Steps to Reproduce:
1. Create a hardlink to a mail-folder (ln mozilla-thunderbird/XXX/Mail/Incoming secondHardLinkedFile)
1.a) Content of both files is the same.
1.b) Receive Mails, and move and... so on. Still the same.
2.Press on Mail folder (Incoming) (right click) "Compact/Compress".
3.The content of the both files (Incoming <> secondHardLinkedFile) is different.
Actual Results:  
I had two files on the hard disk, one attached to my mail folder and another, old, out of date one. -> The hard link was broken.

Expected Results:  
I would have expected to let it be one file. After compressing i should be the same file.

I use Debian Linux. The informations above should be sufficent.

Comment 1

[David :Bienvenu]

I don't have access to linux to test this. Rewriting the data twice would be twice as slow - would there be a way to recreate the link?

Comment 2

[ISHIKAWA, Chiaki]

I think currently TB creates the new compress folder file, and then
delete the original and renames the temporary compresses folder file to the
original name.

From the OS perspective, this is how hardlink should work on linux (or POSIX).

>2.Press on Mail folder (Incoming) (right click) "Compact/Compress".
>3.The content of the both files (Incoming <> secondHardLinkedFile) is
different.

The reason that this secondHandLinkedFile remains is because the
hardlink count of this file is not zero: the submitter says there is a hard link created for this file.

Usually for many users, no such hardlink is created, and hence when TB removes the link to it (i.e., delete it), the hardlink count becomes zero, and
the file is removed from the file system.

In the submitter's case, the hardlink count is not zero, and thus
the file (under different name) remains.

My suggestion is
 - don't try to share the Inbox with other mail clients :-), or

 - or if the other client accesses this file for only READ-ONLY, then
a possible work around is NOT to create a hardlink to Inbox, but
use a SYMBOLIC link to Inbox (assuming the other clients don't have
to modify Inbox file itself  to record the reading status and such. I assume this is the case. Otherwise, the original submitter may be in for a surprise from now and then.)

With a SYMBOLIC link as opposed to hardlink, the problem is avoided. The other mail clients always look at "Inbox" file using the directory entry for the name "Inbox" (even when Inbox may disappear for a fraction of second when the final renaming of the temporary compressed file takes place.)

Comment 3

[Wayne Mery (:wsmwk)]

bienvenu - WONTFIX?

Comment 4

[David :Bienvenu]

yeah, I think so. But if someone comes up with a fix that doesn't make compact twice as slow for everyone else, we'd consider it.