| Summary: | Cannot remove directrory which was used for file download | ||
| Creator: | brkerez | Date: | 2008-08-19 05:44:43 |
| Project: | K-Meleon | Owner: | .Nobody |
| Status: | Open - Mozilla Bug | Severity: | Normal |
| Version: | 1.5.0 | Target Version: | Unknow |
User-agent: K-Meleon/1.5.0b2
Steps to reproduce problem:
1. Download some file with KMeleon and save it to the disk to some directory (doesnt matter if newly created for download or some already created)
2. When download is complete delete downloaded file
3. Try to delete created directory previously choosed for saving downloaded file - it's not possible. It is complaining that it is used - probably KMeleon is holding file resource and so its not possible to delete it
I tested it on WinXP and Win2000 with latest SP's and fixes installed
Sorry for not reacting for so long. When I was posting this bug, I had it confirmed by using Unlocker (http://ccollomb.free.fr/unlocker/)
Here is log handle output - one line that shows that download directory is locked by k-meleon (CurrPorts 1.48 is directory).
k-meleon.exe pid: 8496 ACAPULCO\ptrka
A70: File (RW-) X:\!download\admin\CurrPorts 1.48
Only happen when you're an administrator
Happen in mfcembed -> flagged as mozilla bug
Should be tested with seamonkey
[Changed Status from "Unconfirmed" to "Open - Mozilla Bug"]
bug 1090 was closed as a dupe of this one.
Tested with 1.5.4 and 1.6a4, the problem continue and also happend when you download in local hardisk and try to delete/rename the folder that contained the file downloaded.
The same for "Save Page As..." option.
This problem not happend in Seamonkey 2.0.5.
It's strange because the downloaded file can be deleted but not the folder, because folder is busy by K-Meleon.
I think K-Meleon code not close the I/O steam to write the file or not free the folder after of download/save.
After a lot of test, Dorian is right, the problem origin is MFCembed.
I can reproduce it in all versions of MFCembed that I can tested it.
The problems happend in all KM versions but not in Mozilla, Seamonkey and Firefox versions.
Exactly the problem is MFCembed lock the last folder used to download or "Save As..." a file.
This avoid to rename/delete the folder or unpluge an USB memory to safe way if folder is in an USB memory.
I think the problem is in nsWebBrowserPersist.cpp file of the MFCembed code.
Perhaps nsWebBrowserPersist::SaveDocument() function in this line (421):
mFirstAndOnlyUse = PR_FALSE; // Stop people from reusing this object!
I bet to change it to:
mFirstAndOnlyUse = PR_TRUE; // Stop people from reusing this object!
Also this line is repeted in lines: 378 and 396.
No that's not it. But the problem is probably somewhere in this file and would need to be debugged to be found.
This part of gecko is no more maintained I guess.