149647 - Download manager displays error when downloading to write protected folder

Status: RESOLVED FIXED

(SeaMonkey :: Download & File Handling, defect)

Description

[Johannes Lietz]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    20020530

I tried to download a file via http. As location for saving the file locally I
chose a folder that is write protected.
Mozilla downloads the file, and after the download is completed, it discoveres
that the chosen location is write protected and displays some error message,
saying that you should change the folder's properties or choose another
destination folder. 
Nevertheless the download is lost and you have to start all over.

Reproducible: Always
Steps to Reproduce:
1. Download a file from the internet
2. choose a folder that has write protection
3. 

Actual Results:  A simple error message and the downloaded file is lost.

Expected Results:  Mozilla should warn that the destination folder is write
protected before download or display the file dialog window again to choose a
new destination after the download is completed.

Comment 1

[Johannes Lietz]

I just discovered the downloaded file is not lost, you just have to start
downloading the file from the website again and choose another location. 

But this is disturbing anyway...

Comment 2

[Jason M. Abels]

Sounds like a valid bug. Can you still reproduce on a modern build?

Comment 3

[Johannes Lietz]

Yes, it's still the same in 1.4rc3.

Comment 4

[Jason M. Abels]

confirming

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

sounds similar to bug 216243, marking dependency

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

OK, this should be fixed now by bug 216243.

Could you verify that this is fixed, by using today's nightly builds or 1.5beta
(when it comes out, which should be soon)? thank you.

Comment 7

[Johannes Lietz]

Yes, this bug is fixed now (in 1.5b).

Comment 8

[Stefan [:stefanh]]

Marking fixed, per comment #7.