663071 - Saving an attachment to an almost full filesystem generates an erroneous error message(linux), and leaves an incomplete partial file.

Status: NEW

(MailNews Core :: Attachments, defect)

Description

[ISHIKAWA, Chiaki]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10

When I attempt to saving an attachment to a message
to an almost full file system (by left double-clicking on the attachment),
TB3 shows displays an misleading error message and then leaves an incomplete
partial file in the target directory.

Misleading error message is something about
"The application has run out of memory for the intended operation, 
please restart Thunderbird and try again."

(The message appears in Japanese, and I am not sure what the English message would be.)

Retrying after restart would not succeed since the file system would remain full
by the partially saved incomplete file.


Reproducible: Always

Steps to Reproduce:
1. Creating a low free space condition in a file system.
2. Try saving a large attachment that will overflow the file system.
3. During saving, TB3 generates a misleading error dialog and leaves the partially saved incomplete file behind.


Actual Results:  
TB3 shows a misleading error message and leaves
a partially saved incomplete file.

Expected Results:  
TB3 should show a error dialog that states clearly that the file system
became full, and
should remove the partially saved incomplete file.


Checking the saving of attachment to 
an almost full system under linux is prompted by
the other post
http://bugzilla.mozilla.org/show_bug.cgi?id=429827#c149

about a bug under XP under similar conditions.
http://bugzilla.mozilla.org/show_bug.cgi?id=632431

Under XP, it was reported that not only the file, but the file system got corrupted.

Below is a shell command that creates 5MB volume (and the created
filesystem on
it is much smaller 3.x MB due to the overhead of i-node table, etc.)

I tested saving attachment to the /mnt/5mb-fs above.
(Saving /usr/lib/libc.a which was about 2.5 MB)

---- create-5mb-fs.sh
:
#
LANG=C 
LC_ALL=C
export LANG LC_ALL

LOOPDEV=/dev/loop0
FILENAME=/tmp/5mb_file

# size

PATH=/sbin:/usr/sbin:$PATH
export PATH

dd if=/dev/zero of=${FILENAME} bs=1024 count=5000
losetup ${LOOPDEV} ${FILENAME}
mkfs -t ext3 ${LOOPDEV}
mkdir /mnt/5mb-fs
mount ${LOOPDEV} /mnt/5mb-fs/
ls -l /mnt/5mb-fs
---- end 

It should be easy to test the similar situation using the small filesystem created in this manner.

By running strace -o /tmp/t.out -p pid-of-thunderbird process,
I notice that NOSPC (no space error condition seems to have been noted and subsequent write stopped after one re-try, but
the error handling from there is not quite right. And I am not even sure
if the saved file is closed() explicitly.
[Because the output of strace becomes very huge, I run strace immediately before I hit [SAVE] button, and stopped it immediately after
the error dialog is shown and closed by me. strace  output that covers
that period doesn't seem to contain the close statement against the file descriptor that is used to write to that file if I am not mistaken.

Comment 1

[ISHIKAWA, Chiaki]

> ---- create-5mb-fs.sh
> :
> #
> LANG=C 
> LC_ALL=C
> export LANG LC_ALL
> 
> LOOPDEV=/dev/loop0
> FILENAME=/tmp/5mb_file
> 
> # size
> 
> PATH=/sbin:/usr/sbin:$PATH
> export PATH
> 
> dd if=/dev/zero of=${FILENAME} bs=1024 count=5000
> losetup ${LOOPDEV} ${FILENAME}
> mkfs -t ext3 ${LOOPDEV}
> mkdir /mnt/5mb-fs
> mount ${LOOPDEV} /mnt/5mb-fs/
> ls -l /mnt/5mb-fs
> ---- end 
> 

Run this as superuser and don't forget to make the directory
world-writable

chmod a+rwx /mnt/5mb-fs

Otherwise, you can not write to it and will be bitten by another bug
when you left-click (doubleclicking) on the attachment and trying to save the
attachment.
Bug 567585
(the saving will fail silently without visible error-feedback.)

Comment 2

[ISHIKAWA, Chiaki]

I have checked the operation under the latest comm-central(checked out a few days ago).
The version ([help] -> about thunderbird) says
10.0a1

The message has changed slightly, but still
misleading nonetheless. It doesn't say that it is the device/filesystem that is getting full explicitly.
I am attaching a screen dump to show the dialog.

Comment 3

[ISHIKAWA, Chiaki]

Attachment: Dialog shown on the screen (TB 10.0a1)

This is the dialog with slightly misleading message when an attachment is saved
to an almost full file system resulting error.

Comment 4

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.