1428451 - Saving attachment fails when target directory is a symlink

Status: RESOLVED INVALID

(Thunderbird :: OS Integration, defect)

Description

[Michał Kosmulski]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171115002005

Steps to reproduce:

When viewing an e-mail containing attachments, right-click one of them and choose "Save As...". In the file save dialog, navigate to a directory which is a symbolic link and click "Save".


Actual results:

An error message saying "Unable to save the attachment. Please check your file name and try again later." appears (twice in a row) and the file is not saved.


Expected results:

File should be saved to the indicated directory. Saving to directories which are not symlinks works as expected.

Comment 1

[Jorg K (CEST = GMT+2)]

As you may know, Thunderbird is built on Mozilla core software which is also used in Firefox.

So could you please attempt some "save" operation in Firefox, like saving a web page, exporting bookmarks or downloading something with "Save link as". Each time, select a directory via a symlink. Please report back if this works.

I have the sneaking suspicion that symlinks are not all that well supported, see for example bug 1427192, but I have been wrong before.

Comment 2

[Michał Kosmulski]

Saving an image and saving a complete web page work as expected in Firefox 57.0 for a directory which is a symlink, the same one which fails for Thunderbird.

Some more information about the issue:
* I get the same error if a symlink appears anywhere in the save path, not only in the leaf directory, so e.g. /home/mylogin/<symlink> and /home/mylogin/<symlink>/regular.dir/ behave in the same way.
* The exact version is Thunderbird 52.4.0 on Debian Stretch (52.4.0-1~deb9u1). Before I upgraded my distro, I had Thunderbird 52.3.0-4~deb8u2, and saving files in symlinked dirs worked before that upgrade.

Comment 3

[Jorg K (CEST = GMT+2)]

(In reply to Michał Kosmulski from comment #2)
> * The exact version is Thunderbird 52.4.0 on Debian Stretch
> (52.4.0-1~deb9u1). Before I upgraded my distro, I had Thunderbird
> 52.3.0-4~deb8u2, and saving files in symlinked dirs worked before that
> upgrade.

Thanks for the information. We certainly didn't make any changes to saving files between 52.3 and 52.4. We'd have to look at a list of changes to Mozilla core software during that period. That's going to be a bit, well, time consuming. Also we'd have to check why saving attachments in TB is affected when saving things in FF is not. Sigh.

Alice, you only look for regressions using Windows, or can you do Linux as well?

Aceman, Richard, can you confirm this bug? I'm sure you know how to create a symlink in Linux:
ln -s /path/to/file /path/to/symlink or just
ln -s /path/to/file symlink

Comment 4

[Jorg K (CEST = GMT+2)]

Maybe just checking this in the debugger would help to see where the error is generated.

"Unable to save the attachment. Please check your file name and try again later." is saveAttachmentFailed which is generated here:
https://dxr.mozilla.org/comm-central/rev/007155df7eb96eaa992085feb7e086d61d96e577/mailnews/base/src/nsMessenger.cpp#741
No wonder that the error is displayed twice, it's displayed as alert and then returned from the function, so it will most likely be displayed again.

But the error is of course raised elsewhere deeper down in the bowels.

Comment 5

[Alice0775 White]

I cannot reproduce the problem.
It works as expected on Tb52.5.2 and Daily59.0a1(20180103030201) Ubuntu14.04 64bit.

Comment 6

[Richard Marti (:Paenglab)]

Works here too on Linux Mint with TB52 and Daily.

Comment 7

[Jorg K (CEST = GMT+2)]

And you are 100% sure that there was a symlink somewhere in the path, right?

Comment 8

[Richard Marti (:Paenglab)]

Who do you ask? I'm sure, I saved directly into the symlink, not the symlinked, directory.

Comment 9

[Michał Kosmulski]

Now this is interesting. I ran some more experiments and realized it's not the fact of using a symlink that matters but the directory it points to. When I create a symlink within my home directory, saving into it works just fine.

What sets apart the directory I'm having issues with is that the symlink points outside of my home directory - I have a separate partition for large files, mounted at /home-extra and the link points to a subdir of that. I tried to create other directories outside of my home dir, on the same partition, and when the symlink points to such a directory, saving fails as in the original report. I even tried setting myself and my group as the owner of each directory level upwards of / and setting access flags of all of them to 777 - I still can't save there.

Funny thing is, I just realized I can't save in that directory when I navigate to it directly rather than through the symlink. But I can freely create files there from other applications or from the command line - it's not a matter of owner/group/mode at the OS level.

On the other hand, I was able to save both directly and through a symlink in a directory I created under /tmp.

Comment 10

[Jorg K (CEST = GMT+2)]

Thank you, Richard.

I think we'll let the reporter investigate the problem a little further. All I know is that under the covers symlinks are resolved using the Linux call 'realname' and then we write to that file. If you can't write to the file not using the symlink, then that would explain the behaviour you've seen. I'm just wondering why FF is different.

Comment 11

[Michał Kosmulski]

Further observations:

When I right-click an image in HTML e-mail (remote content, which I allowed for this particular sender) and choose "Save Image As", the Save As dialog opens and when I select my directory which is a symlink, I get no error message but the file is not created, either. When I navigate to the target directory directly rather than through the symlink, the result is the same. So, behavior is similar to that when saving an attachment in that the file is not saved, but differs in that I don't get any error message.

Another strange issue is that after the upgrade Thunderbird doesn't attach the e-mail signature from .signature in my home directory (both the signature and all levels of directory hierarchy are regular files/dirs, no symlinks). The file clearly exists and is readable. I had to disable 'Attach the signature from file instead ...' option and enter the signature text directly in the configuration dialog in order for it to work.

Comment 12

[Richard Marti (:Paenglab)]

Can you check in Preferences/Advanced/General > Config Editor... if ui.allow_platform_file_picker is on false? If yes, try with set to true (double click).

Comment 13

[Michał Kosmulski]

It was set to true already. I tested after setting it to false (just in case) but behavior was still the same.

Comment 14

[Michał Kosmulski]

After some standard updates to my Debian system, the problem went away. Thunderbird is currently at 52.6.0 but the problem may have been in some external library as well.

Comment 15

[Benjamin Flanagin]

Sounds like it was something in Debian. Setting as invalid