700114 - Download of a file fails to save to a read only folder (or without permissions) and doesn't report error (in Firefox)

Status: NEW

(Toolkit :: Downloads API, defect)

Description

[Gabriel Gagliano]

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

Steps to reproduce:

 I clicked in a download link and tryed to save the file in a folder whose write permission I do not have.


Actual results:

When clicking in a download link and the save pop-up appears, if you navigate to a folder where your user don't have permission to write or if the folder is mounted read-only, Firefox does not save the file, does not report any error message and does act as the file was properly saved. Some downloads are paid and this loss of data may cause problems, because a second click in the link is needed and the download process must be restarted.


Expected results:

Before trying to save the file, Firefox should have investigated the folder and should report useful error messages, like "You don't have permission to write there!" or "This file-system is mounted read-only!", so the user has the change to navigate to another folder and try to save the file again. By doing so, no file will be lost and download will never fail.

Comment 1

[:aceman]

Is there anything in the tools->web developer->Error console?

Comment 2

[:aceman]

I can reproduce this on Linux.
I get a proper error message that the download failed due to permissions only when saving via Save page as, and also Save link target as.
But when the download is initiated via normal click on a link (try e.g. https://www.kernel.org and choose a patch file there). There is no indication of download (not in the Download manager) and no error message. The download is ignored.

Comment 3

[Gabriel Gagliano]

Yes!! I reached this bug while using Ubuntu Linux 10.10 and Firefox 7 (sorry, I never tried it under others OS). The Download is totally ignored and the Download window does never open.

Comment 4

[ISHIKAWA, Chiaki]

Hi,

I an trying to fix bug Bug 567585
TB3 fails to raise an error when it tries to save an attachment to write-protected directory.

Actually TB7 (and a built from comm-central) still suffers the same problem.

AND, I believe at least the half the problem reported here for 
FF originates from the same bug and we can 
blame  nsHelperAppDlg.js which is being fixed by me in bug 567585.

This javascript file is invoked in TB when
 - when the user clicks (left double click) on the e-mail attachment
but NOT invoked when
 - when the user clicks on  "save as" context menu (right mouse button first and then choose the "save as" from the pop-up menu.) or the menu button, save near the right lower corner of the message pane is clicked.
In that case, a CPP routine is invoked. 

Confusing, er?

I don't really believe the pre-check is so useful as long as
the error is properly reported afterward.
This is because, if we use a remote server, or on a busy machine,
someone else or one of your processes may be changing the
permission of the directory or even removing the directory
*AFTER* the filepicker (filechooser or whatever it is called) allowed you to select as the destination directory and *BEFORE*
your program starts to open and write to a file under that directory. 

The only sure way to check whether a file can be created for writing is to open it on Posix when the remote file servers and 
multiple processes are involved.

My latest patch in Bug 567585 is something that addresses the situation where target directory that is known to exist (and checked by the filepicker) disappears before writing to it.
In fixing the bug, I encountered a serious problem of not being able to pick up error message, and was forced to write an equivalent of strerror() for mozilla javascript routine.
 
Anyway, the filepicker (or filechooser) seems to try to
at least in principle, to avoid non-writable directory when it was asked to save something.

HOWEVER, I think the check is not working on POSIX-like OS such as Solaris, linux, etc. because  isWritable() implementation used by filepicker under UNIX is, IMHO, broken.

http://mxr.mozilla.org/comm-central/source/mozilla/xpcom/io/nsLocalFileUnix.cpp#1384

1384 nsLocalFile::IsWritable(bool *_retval)
1385 {
1386     CHECK_mPath();
1387     NS_ENSURE_ARG_POINTER(_retval);
1388 
1389     *_retval = (access(mPath.get(), W_OK) == 0);
1390     if (*_retval || errno == EACCES)
1391         return NS_OK;
1392     return NSRESULT_FOR_ERRNO();

See line 1389. If the access() above succeeded then
we would have *_retval as boolen true, and isWritable()
will return NS_OK. So far so good.

But look at "|| errno == EACCESS".
I have no idea why it is there. (Well, actually, I can guess why, but let us not go into the details.)
Suppose we have a directory that is completely
invisible to the user. 
E.g.,
(as a superuser)
  # mkdir /tmp/i-dir
  # chmod a-rwx /tmp/i-dir

I believe the above isWritable() return bollean true for /tmp/i-dir because
the errno == EACCESS is true (!).
But can you write to it? No!

However, at least, the filepicker today tries to check the "Existence" of the directory, and if a directory doesn't exist, it will fall back to another directory. 

This is where I think the reporters above
probably say that nothing happens. 

Maybe TB and FF are slightly different here.

Under TB,
for example, if the user tries to save to a directory, say,
/tmp/c-dir, and while the user is looking at the directory,
suppose,  from another shell in a different terminal window, you invoke "rm -fr /tmp/c-dir" and eliminates that directory.

When the user tries to save to /tmp/c-dir, file picker refuses and move the "focus", i.e., where target is, to "/tmp/" directory, and lists the entries below "/tmp".
"c-dir" is no longer there.
(Actually, filepicker moves very fast, and by the time the user
tries to press [save] while he/she thinks is trying to save to /tmp/c-dir, filepicker may already shows the listing of /tmp, and not /tmp/c-dir anymore.)

However, at this moment when the user is looking at /tmp directory listing in filepicker, 
if someone creates "/tmp/c-dir" then
the c-dir entry appears in filepicker's listing, and so the user can move into /tmp/c-dir. 
You can try deleting and creating a directory and
try saving to, say, "/tmp/c-dir" and see what happens
by running something like
 while true
 do
  mkdir /tmp/c-dir
  sleep 2
  mkdir /tmp/d-dir
  sleep 2
  rm -fr /tmp/c-dir
  sleep 2
  rm -fr /tmp/d-dir
  sleep 1
 done

Be sure to open "error console" because maybe once in a while
the filepicker allows the passing of "/tmp/c-dir" about to be removed in a split second before TB/FF saves something there and
the code throws an error that is never caught and thus you will
see an uncaught error in error console. (Well, this is how I 
debugged the latest patch to Bug 567585.)

Now, ever wonder why this problem to "non-writable directory" 
seems to be ignored by Windows users?

(Non-existing directory, such as in the case of flakey USB drive
going off-line under Windows
and TB/FF allows the user to write to it and causing a failure has been reported. Probably the same cause and
the bad runtime behavior is my guess.)
 
When I tried to create the non-writable directory on my LOCAL
PC using
attrib +r
or 
chmod a-w of Cygwin,
such a directory seems to be created.
But for some unknown reason, TB on Windows
never balked at writing to it. And Windows seems to allow writing to the directory (!?)
I have no idea what is wrong here.
Maybe because my account on *LOCAL* Windows PC has the administrative privilege?
(If so, I can understand the scarcity of complaints about
silent failure to save an attachment to non-writable directory.)
 
Oh, can people follow this bug under linux try to write to, say, 
"/dev/" or mounted CDROM file system?

The silent failure would make people contemplate how this bug
has been ignored for so long.

By the way, there is another issue of save/store location AFTER
the failure occurs. Maybe you may notice that the
next time you try to save, suddenly the first choice moves to
your default save location.
But this default save location is different for
TB and FF.
And the javascript code is shared between TB and FF.
This is again very confusing :-(

Even showing "Download" window is very confusing to TB users since "saving attachment" always means that you have already
has an e-mail message in your local folder and seeing
"download" progress window is hilariously confusing (!).
Maybe I should file a bug on this point alone, but a few similar bugs regarding the unusefulness of download window when
saving an attachment is done from TB (and I recall doing so long time ago before I realized the true cause of the problem: sharing of nsHelperAppDlg.js between FF for downloading, and
TB for saving an attachment.

Thank you for reading this long rant.

I hope the reporters here would encourage the adoption of
patch in bug 567585 so that we can get rid of the problem
soon.

Comment 5

[:aceman]

Thanks for your explanation. I have made the dependence on your bug 567585. We will see if it helps this problem. Thanks for looking into those parts of code.

Comment 6

[ISHIKAWA, Chiaki]

Additional observation.

10.02
(under linux: )

Using [File] -> [Save as]
If I set the default download directory to a directory without write-permission in advance, FF seems to silently fails to write to the directory, BUT resets the default directory to the ~/Download or whatever is the build default of FF and happily writes to the directory(!) 
The default download directory location is reset to
the built-in default when this happens. Hmm...

I am not sure if this under-the-hood recovery without warning
at all is a good idea. (After all the user made a choice.)


Right clicking on a link, and choose the "save as" from the
pop-up context menu and chooses a write-protected directory to
save the file fails SILENTLY as reported before.


Now, under WINDOWS,  but
it seems that the write-only
property on local disk file system (at least this is
I can test easily) seems to be ignored by
mozilla I/O library (presumably if the user has admin permission.
I never failed to write to a directory no matter what I do using
attrib under Windows console, or
chmod in cygwin console to set the write-protected property of
a directory.)
This may be a problem, though, from a security point of view.

OH, wait, under windows, if I create a directory, and then
sets the write-permission status as attrib or chmod (under cygwin), it seems that ONLY the FILES created BELOW that directory seem to be set to READ-only.
We can still create 
a file under it (I was checking the PROPERTIES of the directory
using windows GUI and noticed this. The modification property of the directory seems to be still available to users. But this may be due to the user accounts on my Windows PC have administrative
privildge.)

At least my last observation explains why we have seen less
such reporting of write-protected directory causing problems
coming from Windows users in contrast to linux/solaris/etc. users
who have suffered and reported these problems including myself.

Presumably, even windows users will experience the same problem
when they try to write to a write-protected file server.

Someone more familiar with Windows ACL setting can disable the
write to a directory completely and check how FF (and TB) operates under the windows.


.