Download directory locked from Windows Explorer

VERIFIED DUPLICATE of bug 100381

Status

SeaMonkey
General
VERIFIED DUPLICATE of bug 100381
16 years ago
13 years ago

People

(Reporter: mike caetano, Assigned: asa)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.

Comment 1

16 years ago
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
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 3

16 years ago
Verifying.  Reporter: This should be fixed in builds after Oct. 12.
Status: RESOLVED → VERIFIED

Updated

16 years ago
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.