94756 - check for writability when overwriting existing file

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Phil Randal]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3+) Gecko/20010809
BuildID:    2001080904

When downloading a file on top of an existing file of the same name, Mozilla
does not check that that file is writeable (i.e., not read-only).  As a result,
the download continues with no error message and the downloaded file in a temp
directory

Reproducible: Always
Steps to Reproduce:
1. Mark mozilla-win32-installer-sea.exe read-only
2.  Attempt to download from the above url
3.

Actual Results:  Download continues and completes, leaving the new file in a
temp directory and the old file unchanged

Expected Results:  I'd expect a dialog box informing me that the target file is
read-only, and asking me to continue or abort

Comment 1

[rcummins]

Build 2001081003, w2k

...Following the above procedure, I get a dialog box that says "You do not have
permission to write to the target location, or, the disk is write-protected. 
Choose a different target location", and nothing is saved in the temp folder. 
I'll look for a win98 box around here to try this on.  (Aside, there does seem
to be an extra comma after the 'or' in the message in the dialog box.)

Comment 2

[Alfonso Martinez]

confirming this on win98 and moving to Networking: File.

The native "save file" dialog warns that a file exists, but doesn't check that
it is read only. 
After the download finishes, the original file remains the same, and the
downloaded seems to be in the tmp folder.

Anyway, this bug seems similar to bug 87438.

Comment 3

[Doron Rosenberg (IBM)]

really moving

Comment 4

[Doug Turner (:dougt)]

Bill, I think that the client should be checking permissions of the destination.
 If you disagree, please reassign back to me.

Comment 5

[benc]

is this a necko behavior or an xp app function?

Comment 6

[benc]

+qawanted - need to check all plats.

So this is working on Win2k, broken on W98?

Comment 7

[Bill Law]

I think it is broken on all Win32 platforms.  The one report just tried saving
the file using a different technique (that isn't broken).

Comment 8

[benc]

Please provide the exact steps you use for downloading. (what you selected, 
clicked etc...)

Comment 9

[Alfonso Martinez]

Steps:
1. Mark a file on your HD as read-only (in my case agsmail.exe)
2. Go for example to http://ftp.mozilla.org/pub/mozilla/nightly/latest/ and
click on mozilla-win32-installer.exe 
3. Standard windows filepicker appears. Select the file marked as read-only as
the filename to the new one.
4. A Windows' warning appears about the file already existing (no mention to ro)
5. Mozilla download progress dialog appears, file is downloaded.
6. Go to check the downloaded file: it is still the original one.
7. A file with the the proper size and current date appears in profiledir/cache.
Renaming it to setup.exe shows that this is the downloaded.

tested in Win98 Spanish, Mozilla build 2001092503

Comment 10

[Bill Law]

This is another symptom of the lack of error handling in the 
uriloader/exthandler file save code.  I've got other bugs on that; this one 
will be fixed as well.  If I can find the specific bug number, I'll make this 
one dependent on that.  Most discussion will occur in the other bug(s).

Comment 11

[Alfonso Martinez]

If this problem exists in all the win32 it can be easily fixed. 
It means that the proper flags aren't set when calling the OS dialog, just add
0x8000 to the flags and the OS itself will avoid that a read-only file can be
selected as destination.

Comment 12

[benc]

->file handling (component and qa).

For now, I'll own testing of stuff involving read-permissions, but leave the 
writing stuff to the download people.

Comment 13

[Bill Law]

Mass moving bugs that won't get fixed this milestone.

Comment 14

[Bill Law]

Attachment: Patch to use OFN_NOREADONLYRETURN when picking a save-to file

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 66234 [details] [diff] [review]
Patch to use OFN_NOREADONLYRETURN when picking a save-to file

sr=[e-mail]

Comment 16

[Charles Manske]

Comment on attachment 66234 [details] [diff] [review]
Patch to use OFN_NOREADONLYRETURN when picking a save-to file

r=cmanske
good idea!

Comment 17

[Bill Law]

fixed

Comment 18

[sairuh (rarely reading bugmail)]

vrfy'd fixed using 2002.07.23.08-1.0 comm branch bits on win2k.