User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20080702 SeaMonkey/1.1.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20080702 SeaMonkey/1.1.11 After modifying a Web page on my hard drive, I tested it via file-upload to the cited URL. After that, I could not save any further changes to the file. Instead, I would get an error popup with the following message: "The document xxx is in use by another application and cannot be accessed." where "xxx" was the complete path to the file on my local PC. In order to save further changes to the file, I had to terminate SeaMonkey. Before that, I tried saving the file to a new name, deleting the old file, and then renaming the new file to the old name. However, I was blocked from deleting the old file by the same error popup. This problem is somewhat new, within the current year. It appears that SeaMonkey locks the file as still in use during the upload process and then fails to release it when the upload process is completed. Reproducible: Always Steps to Reproduce: 1. Create a test HTML file on a local hard drive. 2. Test the HTML at the cited URL by uploading the file (second option tab). 3. Open the file, make a minor change (perhaps correcting an error found by the W3C validator), attempt to save the result. Actual Results: An error popup will appear. The changed file cannot be saved. Expected Results: The changes should be saved. This problem does not happen when I use SeaMonkey to view the file, only when I upload it to the Internet. I use a non-Microsoft, non-Mozilla application to upload files to my ISP's Web server. This problem does not happen when I use that application. This indicates to me that the problem is within SeaMonkey and not Windows XP.
Created attachment 334706 [details] Test file Uploaded a test file to see if this bug affects uploading attachments to Bugzilla.
After uploading the attachment cited in comment #1, I logged-off from Bugzilla but did not terminate SeaMonkey. I was then able to modify and save the file while using Notepad, but I was unable to save modifications while using Wordpad. This apparently indicates a difference in how those two Windows applications treat locked files. I was also unable to rename or delete the test file. This indicates the problem does indeed exist for attachments uploaded to Bugzilla.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4) Confirming the locked file issue: Usually, I upload my patches to BugZilla by attaching them to an existing bug: works fine. I sometime use the W3C validator but I don't remember seeing this issue. Recently, for the first time, I attached a patch to BugZilla directly in the bug creation form ... and got this bug. *** Now, someone needs to test SM 2.0a1pre.
Version: unspecified → Trunk
I've seen this many times in FF2 and FF3. It doesn't always happen and the lock goes away eventually.
I've also seen this in FF3 a few days ago. Uploaded photo files, then wanted to move those files to a different folder but they were locked until I terminated (and restarted) Firefox. This is frustrating. Could somebody please correct this? Doesn't seem to be a big thing to do... I didn't wait for the lock to go away on its own, but if this is true, it sounds like a garbage collection release to me. The file would be locked by an instantiated object for the upload, and when the upload is completed, the object isn't dispose()'d but just thrown away, waiting for the GC to pick it up and finally free the file. Version: Firefox 3.0.3 de OS: Windows XP SP3
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 As others mentioned, this is reproducible in Firefox, so I don't think this is Seamonkey-specific. It's also not Windows-specific, as I can reproduce it on Mac. In many cases I don't need the file anymore after I've uploaded it, and this means I can't empty the trash until after I quit Firefox because Firefox still has the file open. Trying to empty the trash results in "The operation cannot be completed because the item '<filename>' is in use." Running lsof from the command line shows the file in question is open in firefox-bin.
Component: Download & File Handling → File Handling
OS: Windows XP → All
Product: SeaMonkey → Core
QA Contact: download → file-handling
Summary: SeaMonkey Fails to Release an Uploaded File When Transmission is Completed → SeaMonkey and Firefox Fail to Release an Uploaded File When Transmission is Completed
Since this already had blocking-seamonkey2 requested on it, requesting what I hope is the equivalent gecko flag.
Blocking, though gavin suspects this is a dupe and suggests it can be caused by things that sniff HTTP headers.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
This sounds like a duplicate of bug 183689. David, are you using any of the extensions mentioned in that bug (Firebug, LiveHTTPHeaders, etc.)?
Actually, bug 183689 is about loads from session history at this point. So I doubt this is a dup of that bug, but if the extensions in question are in use this is invalid.
Re comment #4: I have waited as long as 5 minutes without the file being released. How long is "eventually"? Re comment #9: I do not have Firebug. I do have LiveHTTPHeaders. I will remove the latter and try to reproduce the problem. This might take a few days since I just returned from a one-week vacation in Maui via a red-eye flight and do not have my head completely straight. Please note that the related LiveHTTPHeaders bug at <https://www.mozdev.org/bugs/show_bug.cgi?id=19262> (cited in Bug 183689) seems to indicate the problem does not lie entirely within that extension but also has a browser component.
> How long is "eventually"? Depending on what's causing it, until sufficiently many windows/tabs are closed that the relevant objects get garbage collected, basically...
I just ran the following test: 1. Verify problem still exists. It does. 2. Test with file referenced from a tab. Close the tab. Problem still exists. 3. Test with LiveHTTPHeaders window open. After file is no longer referenced, close LiveHTTPHeaders window. Problem still exists. 4. Use Mnenhy to remove LiveHTTPHeaders. Problem still exists. 5. Repeated #4 after a warm reboot of PC (in case removal of LiveHTTPHeaders requires a reboot for cleanup). Problem still exists. 6. Ran a Bugzilla query at bugzilla.mozilla.org, producing a list of 175 bugs. Opened the bug reports for 7 of the bugs, each in a separate tab. Also opened another tab with the history of changes to one of the bug reports. While the bug reports were opening, did a file upload from another tab. After all pages loaded and were displayed (10 tabs open), closed all tabs except for the bug list from the query and the report for this bug #451290. Waited 5 minutes. Problem still exists. Closed the tab for the bug list from the query. Problem still exists. (NOTE: Had not yet re-installed LiveHTTPHeaders.) Conclusions: 1. This does not seem to be related to the LiveHTTPHeaders extension. 2. Closing tabs and waiting for "eventually", does not help. 3. If bug #183689 is caused somehow by LiveHTTPHeaders, this bug is NOT a duplicate.
Mnenhy is an extension that includes a chrome manager, which can be used to remove other extensions. After using it to remove LiveHTTPHeaders, I used Mnenhy again and saw LiveHTTPHeaders was no longer in the list of packages. I then used the SeaMonkey InfoList button of the PrefBar extension; LiveHTTPHeaders was not included in the list of extensions. Finally, on the SeaMonkey menu bar, I selected [View > Page Info]. The Page Info window did not have a Headers tab. All this indicated to me that LiveHTTPHeaders was no longer installed. Of the 6 extensions I have installed for SeaMonkey, 5 are installed in the root and not any profile. This is because I have 4 profiles and want all extensions installed for each profile. Thus, testing with a clean profile would require reinstalling SeaMonkey itself and then -- after testing -- reinstalling the extensions. I won't do this. I may try a clean profile when I install the next "stability and security" update of SeaMonkey (if there is one).
OK. Would you be willing to quickly check whether the problem also appears in a clean profile with Firefox, then? That shouldn't be affected by your SeaMonkey extensions... I'm looking for a Windows system to test on over here, but it might be a day or so before I dig one up.
OK. On Windows Vista, I took a current trunk Firefox build, created a file on my desktop with the name "test.html" and the text "aaa" in it, loaded http://validator.w3.org/, clicked the "Validate by File Upload" tab, clicked the Browse button, selected my file, Clicked "Open" on the filepicker dialog, clicked "Check" on the webpage, then tried to delete the file using the "del" command in the windows shell. There was no problem with deleting. To double-check that the test is reasonable, I tried the same thing with LiveHTTPHeaders installed, and the "del" command gave me the "The process cannot access the file because it is being used by another process." error. So I can definitely reproduce the general file-locking problem using the method above. I repeated the test using the build from ftp://ftp.mozilla.org/pub/seamonkey/releases/1.1.14/seamonkey-1.1.14.en-US.win32.zip with a vanilla profile. Again, there was no issue with deleting the file right after uploading it. It seems that it might be worth your time trying to figure out exactly what about your setup is different... The various extensions you use are the most likely culprits, of course.
i also have this problem with a few cases such as uploading text files to sites or photos to facebook.
Today, I installed SeaMonkey 1.1.15. Since most of my extensions are installed in the SeaMonkey root, this wiped out those extensions -- including LiveHTTPHeaders. Before reinstalling the affected extensions, I tried the test case from my original Description of this bug report. The test case was successful; the Expected Results were obtained. I then installed only LiveHTTPHeaders. The test case failed. Thus, this problem is indeed caused by the installation of LiveHTTPHeaders. However, see the end of my comment #11, which indicates that part of the problem is indeed within the Core.
The LiveHTTPHeaders problem is entirely theirs. If they open the stream and read part of it, they have to read the whole stream. That's the contract for the HTTP POST data stream in necko at the moment. I commented in the LiveHTTPHeaders bug with some actual relevant information. Not a core issue (except insofar as the necko contract sucks, of course).
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.