519115 - Certain downloads create a (strongly) corrupted NTFS file on the hard drive

Status: UNCONFIRMED

(Toolkit :: Downloads API, defect)

Description

[jhenifer_heloizy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

All "semi-automatically" downloaded files from the given site (but not only it) create either one file-system-corrupted file or one correct and a corrupted double of it. The corrupted file is hidden, it cannot be deleted (even after reboot and/or in shell-only safe-mode etc), its attributes cannot be changed, its properties don't display properly, etc. Even chkdsk won't fix it.

This is *apparently* due to a bad filename that is used as-is/unfixed when downloads are set to be automatic. When the destination filename is chosen thru the win32 dialog step, the bug doesn't appear (afaik the name get fixed at this step).

Reproducible: Always

Steps to Reproduce:
1. In options, configure downloads to "Save files to:" and not "Always ask me where to save files" also in windows Folder options enable hidden files display
2. Open http://www.torrentreactor.to/torrents/view_2115824/Linux_Power_Tools.html and click on the Download button
3. Check "Save file" and click OK
Actual Results:  
In the downloads directory lie 2 files (one is hidden, make sure hidden files are displayed). One can delete one of the files but not both. The remaining file is strongly non-modifiable and unmovable, corrupted on the file system level.

Expected Results:  
Only one file should be saved and it shouldn't be corrupted.

Comment 1

[jhenifer_heloizy]

EDIT: "del /A:S /F NAME~8.3" deletes the file with a corrupted name.

Comment 2

[James May [:fowl2]]

Are you saying Firefox is saving a file with an invalid filename?

Comment 3

[jhenifer_heloizy]

(In reply to comment #2)

Yes, basically this is what happens, although it manifests itself as two files having the same apparent name.

Noteworthy is the fact that, without the del commandline I showed, the layman won't be able to delete the file ever. As as sidenote, I think this could be maliciously exploited to create alias files that annoy the user badly.

I think the problem might be with an additional "." at the end of the remote file name, like 'whatnot.torrent.' which might make windows think it's 'whatnot.torrent' and lock up the file entry.

I explained how to reproduce the problem and also how it is avoided. Try it please.