87438 - Silent download should check for write permissions

Status: VERIFIED DUPLICATE of bug 27609

(Core Graveyard :: File Handling, defect)

Description

[coe]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-0.2.9 i686; en-US; rv:0.9.1)
Gecko/20010608
BuildID:    2001060810

If file is downloaded into non-owned directory, file is stored as usual in cache
directory, but fails silently during transfer from cache to destination
directory. There probably should be a check for legality at the file-name
selector stage.

Reproducible: Always
Steps to Reproduce:
1.chose remote download file
2.select download to file
3.select (accidentally read-only) directory

Actual Results:  File downloads as normal to cache. File appears to transfer (no
error diagnostics) to destination directory. Transfer dialoq box closes. Only
inspection shows downloaded file is missing.

Expected Results:  Checked destination directory for legality before starting
download

Comment 1

[Boris Zbarsky [:bzbarsky]]

Over to networking: file.  We start the download before we know the destination,
actually.  But checking on return from the filepicker seems like a great idea!

Comment 2

[Doug Turner (:dougt)]

bill, sounds like this is yours.

Comment 3

[timeless]

yeah there's mention in another bug that this code had absolutely no errror 
checking.  This is probably the third or fourth bug about the same code blocks 
:(

Comment 4

[benc]

Can you give the exact steps, so I can mark dupes for different download 
methods?

timeless: what I want to do is create a bug for each filesystem behavior we 
neglect (write permission, disk full, quotas, etc), and then link a bug for each 
type of file transfer that is affected as a dependency, and then link everything 
else into those bugs as duplicates. I'm crusing through the component, but if 
you have favorites, lemme know.

Comment 5

[benc]

-> file

Comment 6

[Bill Law]

*** This bug has been marked as a duplicate of 27609 ***

Comment 7

[sairuh (rarely reading bugmail)]

mass verification of duplicate bugs: to find all bugspam pertaining to this, set
your search string to "DuplicateBugsBelongInZahadum".

if you think this particular bug is *not* a duplicate, please provide a
compelling reason, as well as check a recent *trunk* build (on the appropriate
platform[s]), before reopening.