Firefox keeps file open on external disk, can't unmount

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

With IBM Websphere Portal console, when I deploy a new WebApp, I need to select a local *.WAR file. After the deployment process, Firefox locked the local WAR file and I'm unable to overwrite/delete it. I need to use an "Unlocker" tool (http://ccollomb.free.fr/unlocker/) in order to 'kill' the lock.

Reproducible: Always

Steps to Reproduce:
1. Deploy a local WAR file in Websphere Portal (6.0.1.16)
2. Try to delete the selected WAR file after the deployment process.
Actual Results:
The file is locked by Firefox

Expected Results:
After the WAR upload, Firefox should not keep a lock on the local file.

about:buildconfig

Build platform
target
i686-pc-mingw32

Build tools
Compiler Version Compiler flags
cl 14.00.50727.762 -GL -wd4624 -wd4952 -TC -nologo -W3 -Gy -Fd$(PDBFILE)
cl 14.00.50727.762 -GR- -GL -wd4624 -wd4952 -TP -nologo -Zc:wchar_t- -W3 -Gy -Fd$(PDBFILE)

Configure arguments
--enable-application=browser --enable-update-channel=release --enable-optimize --disable-debug --disable-tests --enable-update-packaging --enable-official-branding --enable-jemalloc --with-crashreporter-enable-percent=10

Created an attachment (id=363677)
Unlocker prinstcreen

see bug 183689

It's also possible that it's caused by the LiveHTTPHeaders or Firebug extensions, see also bug 183689.

OK, Thanks. I confirm your idea. Without Firebuf 1.3.2, everything works fine.

Confirming, since this bug 183689 comment 93 says this shouldn't be duped there.

Also tracked by http://code.google.com/p/fbug/issues/detail?id=1374. I don't think anyone knows yet whether this is a Firebug bug or a Firefox bug.

See https://www.mozdev.org/bugs/show_bug.cgi?id=19262#c8 for my comments on LiveHTTPHeaders. I'll bet that Firebug has the same problem.

If so, please mark this invalid.

I should note that if necko's whole approach to POST data gets reworked as part of bug 183689 then you might be able to get away with not reading the whole stream. If that happens (somewhat unlikely, since no one owns that code right now), we'll need some coordination to make sure that Firebug and LiveHTTPHeaders will continue to work.

(In reply to comment #4)
> Also tracked by http://code.google.com/p/fbug/issues/detail?id=1374.

Firebug has fixed our part.

Boris, I wonder if you duped in the direction you intended? (ok by me).

If you're talking about bug 183689, then yes, I did.

Sounds like this is invalid.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8

File uploads, for example attaching files to a webmail, keep the file open after the upload is done.

This results in not being able to remove or delete the file after you are done sending it. As a result I first have to open process manager, close the file handle and then I'm able to delete it.

File stays open until I close the browser. Have not tested if it is closed if you upload another file.

Reproducible: Always

Steps to Reproduce:
1. Upload a file via any web page
2. Try to delete the file that you have successfully uploaded
3.

Did you searched before filing this bug ?
Do you use livehttpheaders or Firebug ?
Did you tested it in the Firefox safemode before reporting this bug ?
( http://support.mozilla.com/en/kb/Safe+Mode )

*** Bug 487423 has been marked as a duplicate of this bug. ***

I have the issue with Firebug 1.3.3 so it doesn't look fixed to me.

That's something to report in the firebug bug report, not here, no?

 (In reply to comment #10)
> I have the issue with Firebug 1.3.3 so it doesn't look fixed to me.

The Firebug issues list is at http://code.google.com/p/fbug/issues/list

As a practical matter we will probably not be fixing 1.3 for this issue, so we will ask you to try Firebug 1.4X http://getfirebug.com/releases/firebug/1.4X. Auto update is broken on this version so you will need to install 1.4a18 manually when it comes out.

Ok, the thread in http://code.google.com/p/fbug/issues/detail?id=1374
 indicated fixed for 1.3.1 or I misunderstood (it was a response to comment #7)

This bug still exists in 3.0.8. It happens in both normal and safe mode. File handles remain open after uploading the files.

Forcing the handle to close, by an external tool does not seem to do any harm to FF.

I have tested this in Firefox 3.0.10 and it appears to be a problem with Firebug when you have the Net panel enabled. I turned off the Net panel and the problem disappears. I also tested this in safe mode and it does not keep the file open.

How did this not get nominated for 3.5?

It seems to be related to Firebug though, even without the Net panel enabled. I can't reproduce this in a fresh profile. Process Explorer is handy to see whether the handle is being kept open or not.

Firebug and Live HTTP Headers have both been known to cause this, see:

https://www.mozdev.org/bugs/show_bug.cgi?id=19262
https://bugzilla.mozilla.org/show_bug.cgi?id=479778

Since comment 2 suggests this happens in safe mode, let's ignore those potential causes?

This could also be a dupe of bug 459384.

not able to delete a file uploaded, before closing the fire fox!

*** Bug 507323 has been marked as a duplicate of this bug. ***

I can confirm that this bug is still occurring in ff3.5.1. I also have both firebug (1.4.2) and LiveHttpHeaders (0.15) add-ons installed.

Using Process Explorer (on Microsoft Windows Vista SP2), I am unable to forceably close the file handle (error is "file handle is invalid").

Also, it appears that uploading another file releases the first file handle, so this probably isn't a file handle leak... it's just that the last file uploaded is stuck open by ff/fb/lh.

*** Bug 508521 has been marked as a duplicate of this bug. ***

*** Bug 510721 has been marked as a duplicate of this bug. ***

Blocking for further investigation; QA, can we get a confirmation of this?

Would be helpful to know which sites reporters are seeing this on specifically - I see mention of webmail as well as other sites but no sites specifically.

The site is irrelevant; anywhere where you do a file upload. Bugzilla attachment, webmail attachment, flickr photo.

Spent some time trying to reproduce this in the QA lab on the XP machine using FF 3.5.2. Here are some of the things that I did:

1. Installed both Firebug and Live HTTP headers
2. Uploaded file to flickr, bugzilla test installation, gmail, etc.

I had the Firebug netpanel open when I was performing these operations but I was not able to repro. If someone can give me an exact set of STR and a site that it happens on, it would be very helpful.

Marcia,

When uploading my attachment for tb bug #508609, I ran into this issue. As far as I can recall, I did nothing special: I created an empty file on my desktop, gave it a name, clicked "add attachment" in bugzilla, chose the file and clicked "upload". The file was locked until I uploaded another file (at which point, that new file was locked and the old one was released).

I have noticed that it does not happen every single time (which, I know, is very irritating when trying to come up with a fix).

In any case, one need go no further than Mozilla's bugzilla to find a site where this has occurred.

When I experienced this I was on 3.0.x (I don't remember the version). I just installed 3.5.3 and do not see the problem anymore (though some of my add ons still need updated). Here was my steps:
* Using Notepad, create a .sql file (leave notepad open)
* import that .sql file with phpMyAdmin (basically file upload) from a local install to a local database (successful so notepad does not hold locks)
* edit the file in the still open notepad and save (cannot save file is locked)

To clear the lock I had to close all my FF windows.

Attempted to reproduce this on Firefox 3.5.3, to no avail.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

Installed Firebug - other than Firebug the profile was new, was able to upload and delete file without any problems. Deleting by right-click->delete, right click on recycle bin and empty.

Attempted this several times with and without firebug installed. Just tested with txt files.

also tested on Windows 7 / Fx 3.5.3, cannot reproduce. reporter: Can you reproduce this bug using Firefox 3.5.3?

*** Bug 510154 has been marked as a duplicate of this bug. ***

Not blocking, potentially RESO WFM?

Yeah, RESO WFM. Reporter can reopen if it can be reproduced reliably.

Hi I'm the original reporter. Seems to be fixed for me in 3.5.3.

*** Bug 522197 has been marked as a duplicate of this bug. ***

I can still reproduce this basically all the time on trunk -- same symptoms as original bug, the handle stays open if I upload a file. Firebug is installed, but all the panels are disabled. I have:

Firebug 1.5.0
Flashblock 1.5.11.2
Weave 1.0rc2
Tree Style Tab 0.8.2009122501
Stylish 1.0.7

Handle is visible using Process Explorer.

I am experiencing this problem. In my case I downloaded a PDF document to a flash drive. Windows would not eject the drive until I closed FF.

Firefox 3.6.12
Windows 7 Enterprise 64-bit
Firebug not installed
LiveHTTPHeaders not installed