Closed
Bug 105829
Opened 23 years ago
Closed 23 years ago
Download directory locked from Windows Explorer
Categories
(SeaMonkey :: General, defect)
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.
Comment 1•23 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.
Comment 2•23 years ago
|
||
*** 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
URL: http://n/a
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•