Closed Bug 105829 Opened 23 years ago Closed 23 years ago

Download directory locked from Windows Explorer

Categories

(SeaMonkey :: General, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 100381

People

(Reporter: prionx, Assigned: asa)

Details

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

Saved file directory remains locked from manipulation by windows explorer
after completing a file download. The directory can not be renamed or deleted
until mozilla is shut down or a different directory is selected to received a
subsequent download - that directory remains locked in turn .

Reproducible: Always
Steps to Reproduce:
1. Open URL
2. Select "save as" from context menu
3. Select destination directory - hit ok - wait for completion
4. Open windows explorer to destination directory
5. Attempt to rename or delete destination directory
6. Receive Error Message 
7. Select "save as" from context menu
8. Select different destination directory - hit ok - wait for completion
9. Attempt to rename or delete first destination directory
10. Success
11. Attempt to rename or delete second destinatino directory
12. Receive Error Message
See below for details of error message.


Actual Results:  Error Renaming File or Folder/Error Deleting File or Folder
[x] Cannot rename/delete <directoryname>: There has been a sharing violation.
The source or destination file may be in use

Expected Results:  Once a download completes the directory should not remain in use.
Windows explorer should be able to rename or delete the directory.

The duration between the downloading activity and the attempt to rename the
directory makes no difference. Hours can go by and the last download destination
directory remains locked.
WfM on Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5+) Gecko/20011018

Without looking at the code, I'll make a guess as to what may cause it:
leaking file handles.  If a program leaks a FILE * instead of properly
closing it with fclose(), the file remains open, and Windows Explorer
will refuse to move or delete the file or any folder that contains it.

This may happen on Mac and Windows; it's especially damaging with Quick
Launch mode.  It's not likely to happen on UNIX systems because those
systems associate file handles with inodes.

Reporter: Is the file that you just downloaded marked as being 0 bytes
in size?  That's what Windows reports for newly created files that have
not been closed.

*** This bug has been marked as a duplicate of 100381 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Verifying.  Reporter: This should be fixed in builds after Oct. 12.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.