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

Bug #282865 reported by Adam Porter
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
firefox-3.0 (Ubuntu)
Undecided
Unassigned
Nominated for Karmic by Adam Porter

Bug Description

Binary package hint: firefox-3.0

I uploaded a file from my camera's CF card to a web site. I chose it with the GTK file picker. Then a few minutes later I wanted to unmount the CF card, but kio_umountwrapper couldn't do it, because it said Firefox still had the file (or maybe the directory) open.

As I write this, Firefox still hasn't released the file.

Firefox should release the file as soon as it has finished uploading it.

Adam Porter (alphapapa)
description: updated
Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Could you try to reproduce the same with Ubuntu 8.10 or 9.04? Thanks in advance.

Changed in firefox-3.0:
status: New → Incomplete
Revision history for this message
Adam Porter (alphapapa) wrote : Re: [Bug 282865] Re: Firefox keeps file open on external disk, can't unmount

Sorry, but I don't have Intrepid or Jaunty installed. Regardless of
those distros, however, it is a bug in Hardy.

On Thu, Jan 22, 2009 at 13:40, Pedro Villavicencio <email address hidden> wrote:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in it recently. We were wondering is this still an issue
> for you? Could you try to reproduce the same with Ubuntu 8.10 or 9.04?
> Thanks in advance.
>
> ** Changed in: firefox-3.0 (Ubuntu)
> Status: New => Incomplete
>
> --
> Firefox keeps file open on external disk, can't unmount
> https://bugs.launchpad.net/bugs/282865
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
In , Kprog (kprog) wrote :

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

Revision history for this message
In , Kprog (kprog) wrote :

Created an attachment (id=363677)
Unlocker prinstcreen

Revision history for this message
In , Jo-hermans (jo-hermans) wrote :

see bug 183689

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

Revision history for this message
In , Kprog (kprog) wrote :

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

Revision history for this message
In , Jruderman (jruderman) wrote :

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.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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.

Revision history for this message
In , Johnjbarton (johnjbarton) wrote :

(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).

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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

Sounds like this is invalid.

Revision history for this message
In , RenHoek (ivo-palli) wrote :

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.

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

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 )

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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

Revision history for this message
In , Dlorre (dlorre) wrote :

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

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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

Revision history for this message
In , Johnjbarton (johnjbarton) wrote :

 (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.

Revision history for this message
In , Dlorre (dlorre) wrote :

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)

Revision history for this message
In , Dawk02 (dawk02) wrote :

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.

Revision history for this message
In , Ianrobertperez (ianrobertperez) wrote :

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.

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

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.

Revision history for this message
In , Gavin Sharp (gavin-sharp) wrote :

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.

Revision history for this message
In , Connect-mahesh (connect-mahesh) wrote :

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

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

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

Revision history for this message
ggtamas (ggtamas) wrote :

This bug exists in Firefox 3 on every platform, I reproduced it with Windows XP and Firefox 3.5.1.

Revision history for this message
John Vivirito (gnomefreak) wrote :

Please look for and/or file this bug upstream and drop the link tot he bug report here.

Revision history for this message
In , Chris-christopherschultz (chris-christopherschultz) wrote :

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.

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

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

Adam Porter (alphapapa)
Changed in firefox-3.0 (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
pabouk (pabouk) wrote :

I have encountered the same bug with Firefox 3.5.2 on Windovs Vista SP2.
The discussion related to the problem is here:
http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=174988&forumId=1

The bug in Bugzilla is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=485887

Summary:
1. The bug could be related to Firebug and Live HTTP Headers plug-ins.
2. In some cases this workaround works: Close the tab with the upload form. Undo close tab.

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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

Revision history for this message
In , Beltzner (beltzner) wrote :

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

Revision history for this message
In , Marcia-mozilla (marcia-mozilla) wrote :

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.

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

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

Revision history for this message
In , Marcia-mozilla (marcia-mozilla) wrote :

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.

Revision history for this message
In , Chris-christopherschultz (chris-christopherschultz) wrote :

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.

Revision history for this message
In , Dpower-work (dpower-work) wrote :

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.

Revision history for this message
In , daviddahl (ddahl) wrote :

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.

Revision history for this message
In , daviddahl (ddahl) wrote :

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

Revision history for this message
In , daviddahl (ddahl) wrote :

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

Revision history for this message
In , Beltzner (beltzner) wrote :

Not blocking, potentially RESO WFM?

Revision history for this message
In , daviddahl (ddahl) wrote :

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

Revision history for this message
In , RenHoek (ivo-palli) wrote :

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

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

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

Revision history for this message
In , Vladimir Vukicevic (vvuk) wrote :

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.

Revision history for this message
In , Ken Overly (ken-overly) wrote :

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

Revision history for this message
pabouk (pabouk) wrote :

I see that here is nothing going on...

Just to let you know: I encountered the bug again on Ubuntu 12.04.3 with Firefox 24.0.

Enabled addons:
Adblock Plus 2.4 true {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
DownThemAll! 3.0b5 true {DDC359D1-844A-42a7-9AA1-88A850A938A8}
Element Hiding Helper for Adblock Plus 1.2.3 true <email address hidden>
Greasemonkey 1.12 true {e4a8a97b-f2ed-450b-b12d-ee082ba24781}
HttpFox 0.8.12 true {4093c4de-454a-4329-8aff-c6b0b123c386}
Resurrect Pages 2.0.7 true {0c8fbd76-bdeb-4c52-9b24-d587ce7b9dc3}
Sage 1.5.2b4 true {a6ca9b3b-5e52-4f47-85d8-cca35bb57596}
ScrapBook 1.5.8 true {53A03D43-5363-4669-8190-99061B2DEBA5}
Session Manager 0.8.0.8 true {1280606b-2510-4fe0-97ef-9b5a22eafe30}
Ubuntu Firefox Modifications 2.7 true <email address hidden>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.