Closed Bug 183689 Opened 22 years ago Closed 16 years ago

Loading file upload result page via session history locks file

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 459384

People

(Reporter: jo.hermans, Unassigned)

References

Details

(Keywords: testcase)

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2.1) Gecko/20021130 I know this should have been been fixed a long time ago (see bug 126829), but I'm still seeing this bug in Mozilla 1.2.1. It bites me several times a day. - in my company, I have to use a form to upload documents several times a day, using a <input type=file> field. The file is stored on a network drive (Samba actually) - after the form has been submitted, and I can see another page 'click to continue'), and I can browse to other sites - but when I try to move the original file, or update it for a next edition, I get write errors from Windows NT (sharing violation when you move it, network error when you try to overwrite). Opening and closing the document works ok. - when I close the tab or the window where the original form has been used, the lock is gone. My workaround is to open the form in a seperate tab, submit it, and instead of a 'click to continue', I ctrl-click it, to make sure that I open a new tab. The original tab (where the form was) can be closed, and will release the lock. Are you really, really sure that bug 126829 has been solved ? Or is there a reference to the file descriptor somewhere else ? (session-history ?)
I see this sometimes as well. I can never reproduce it reliably. Does this happen for you all the time? If so under what circumstances.
Priority: -- → P2
Steps to reproduce: 1) On Win NT machine with Samba network, go to form 2) Type in path or browse to file 3) Submit form. 4) Receive confirmation page. Problem: File on server is locked. Closing the browser window unlocks the file on the NT server.
Keywords: testcase
I can't reproduce, but this is an important bug if so. Carine, did you open a file that was on the network? How exactly did you test whether it was locked? I tested http://www.johnkeiser.com/cgi-bin/mozform.pl?method=post&action=http%3A%2F%2Fwww.mozilla.gr.jp%3A4321&enctype=multipart/form-data and uploaded a file that was on the network, then went and tried to change the filename and then delete the file, and both worked. Maybe it's WinNT only, I'm on WinXP 2002121808 and I've never seen it on WinXP.
Target Milestone: --- → mozilla1.3beta
I am seeing this with Moz 1.2.1. I use Moz to deploy an application (720 KB .ear file) to an Oracle 9i Application Server. When I upload the file, Moz indicates that the POST request was still going on, but in fact the request ist finished and the file is successfully uploaded. (but that's not the issue here) Now, the uploaded file is locked on my harddrive and I have to shut down Mozilla in order to get the lock released. This is very annoying since I want to re-build the .ear file from source and the redeploy.
Maybe all of these are a problem with the POST not finishing. It would be very helpfull if someone can supply steps to reproduce which includes the URLs that are used.
Does this happen if you have Mozilla set to HTTP/1.0?
I found a test case that so far works all the time for me. Here is how I can reproduce it. (Windows XP; Mozilla build 20030312 i.e. official 1.3) 1. Create a valid HTML file. I used the following and put it in D:\n\mm\2.html on my system: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML LANG="EN-US"> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <title></title> </head> <body> </body> </html> 2. Open a Command Prompt window and in the directory D:\n\mm type D:\n\mm> rename 2.html 2.html So far, so good. This do-nothing rename works. 2. Open Mozilla, then open URL http://validator.w3.org/ 3. Type the name of the file in the "Local File:" box, in my case "D:\n\mm\2.html" 4. Click the "Validate File" button. 5. On the new page http://validator.w3.org/check, click any external link, for example the W3C logo in the upper left-hand corner. Let the new page finish loading. 6. Click the Back button in the browser 7. In the Command Prompt window, type D:\n\mm> rename 2.html 2.html and it responds: The process cannot access the file because it is being used by another process. Note: The rename works at any point prior to step 6. The Back button click in step 7 is what triggers the file locking.
I also noticed the bug when trying to validate a HTML file on my computer, however i do not need to press back to lock the file. As soon as the file is uploaded, it's locked. I can press links and so on, but the file will keep locked until i close the tab or window.
In Mozilla 1.4a (build 2003040105), I'm not able to reproduce this anymore ... I tried my own test-case, and the one in comment 7.
I am on 1.4a with XP and this bug has been biting every time I upload a file. It is resolved when I close the browser window I uploaded with. The file does not have to be on a network, and I don't have to hit back.
Blocks: 197076
On further investigation it appears that if a window is spawned (through javascript) then the file will be locked until the parent has been closed.
I can reproduce this bug using a form: <form ENCTYPE="multipart/form-data" ACTION="..." METHOD="POST"> <input NAME="userfile" TYPE="FILE"> <a HREF="javascript:void()" onClick="document.forms[0].submit(); return false;">UPLOAD FILE</a> </form> Uploading c:\temp\foo.gif. The file is locked (cannot delete it) until I close Mozilla. (the html is out of my control, if you wonder why a javascript is used...) Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030401
*** Bug 204415 has been marked as a duplicate of this bug. ***
1.4b and it has not been resolved. I had to close the entire instance of 1.4b to be able to delete the file.
-> jkeiser
Assignee: alexsavulov → jkeiser
Target Milestone: mozilla1.3beta → ---
I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030427 Mozilla Firebird/0.6 and this problem still occurs. Steps : 1. Create an HTML file (notepad); 2. Open http://validator.w3.org; 3. Upload the file to validate; 4. Change the file, and save; 5. "This file is used on another process" message box appears on notepad. Workaround : 1. close ALL instances of Mozilla Firebird.
I'm using 1.3 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312) on Windows 2000, and I have this problem too. It's really annoying.
With 1.4RC2 this is still an issue. If 1.4 is going to become the basis for other commercial products then IMO it should be resolved by release.
Target Milestone: --- → Future
*** Bug 197076 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 212470 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
No, 183689 is a duplicate of this.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 212470 has been marked as a duplicate of this bug. ***
This can always be replicated by uploading a file to Yahoo! Briefcase.
I'm not sure if a "top100" keyword requires the bug to be in the actual display of a top 100 site, but if not, this bug affects the number one site on the top 100 list. I can reproduce it daily on WinXP BTW.
*** Bug 204360 has been marked as a duplicate of this bug. ***
No longer blocks: 197076
LiveHTTPHeaders is at fault here. It opens the upload stream by seeking it and reads from it but doesn't close it. That explains why not everyone sees the problem. I fixed it for myself by adding the following line around line 254: this.oHttp.uploadStream.close();
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → INVALID
So how does that make this bug invalid?
because it's a bug in Livehttpheaders and not Mozilla.
Nobody else has mentioned having that extension installed. I'd be surprised if they all do...
Yep. I do.
Please file a bug against livehttpheaders before closing this, unless you are the livehttpheaders owner and have already fixed it. Enough people use that cool extension that this will recur.
I've filed a bug in mozdev.
I do not have livehttpheaders installed. (I verified this by looking at right-clicking on a page and opening 'View Page Info'; there is no 'Headers' tab.) I repeated the instructions I provided in Comment 7, using Windows XP with the latest Mozilla nightly build 2003081515. I can still reproduce the problem, exactly as described in Comment 7. It seems to me, therefore, that there may be another bug in addition to the livehttpheaders bug that has been described here. Minor typo in Comment 7: "The Back button click in step 7 is what triggers the file locking" should be "The Back button click in step 6 is what triggers the file locking".
Reopening because of comment #33.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
OK. I do not have LieHTTPHeaders installed on my Firebird 20030811, and comment #7 fails for me as well. It is really really odd that you have to go back to the page to re-lock the file. It sounds like the network may be doing something with the POST data, which I didn't think it should be doing. Can anybody reproduce this without steps 5 and 6?
(And by "anybody" I mean "anybody without LiveHTTPHeaders installed")
nsDocShell::LoadHistoryEntry -> InternalLoad -> DoURILoad seeks the stream causing the file to be opened. Normally the file would be closed when EOF is encountered but I think that now that the data comes from the cache the stream isn't read and the file is left open. We should not rely on EOF to close the stream. I also find it questionable that nsBufferedStream::Seek calls Fill() at all.
This is still an issue (ugly one) with Mozilla 2003100404 on Windows 2000.
*** Bug 214215 has been marked as a duplicate of this bug. ***
hmmm this bug is still present in mozilla 1.7.2 on win32 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803), its been almost 1 year since the last discussion and it seem its still not patched. Test case of message #7 is still valid. Test case of message #16 is no longer valid.
*** Bug 283192 has been marked as a duplicate of this bug. ***
*** Bug 281759 has been marked as a duplicate of this bug. ***
*** Bug 294355 has been marked as a duplicate of this bug. ***
*** Bug 292005 has been marked as a duplicate of this bug. ***
*** Bug 327884 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 This bug is still present. I don't have a reliable test case. My circumstances are always the same, but it doesn't happen every time. I upload many types of files (html, css, js, gif, jpg, swf, as, etc.) through an input field/'browse' dialog. I always use the browse dialog. The file I'm uploading is generally open on my local machine. I usually switch back and forth between tabs after uploading to check the changes I've made, ending back at my upload form tab. Every so often after this process, the local file is locked by Firefox. Closing the form tab does not release the file for me, as some have posted. I must entirely quit Firefox to release the file.
Still seeing this in Firefox/WinXP, too, on the local C-drive. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Assignee: john → form-submission
Status: REOPENED → NEW
QA Contact: vladimire → ian
Wow, this is *still* an issue. Doesn't matter what drive of course. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
I've just seen something similar, using Firefox 2.0.0.14 on Windows. The file is on a Samba share to a network of Linux servers, and a process on another Linux server (not the Samba one) is updating it across NFS. There are no error messages, and the file looks right using Linux tools, but wrong using Windows tools. The Samba is 3.0.24.
I see this problem in Windows when uploading a file from a local drive using the latest 3.0RC1. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 WinXP Tablet Edition SP3.
I see this bug when deploying war files up to a tomcat server. I am unable to do a rebuild of my application because it can not delete the previous build. Closing Firefox, then building works. I now deploy via my build process (Maven) It started with Firefox 3.0RC1 but could be related to an add on. It didn't happen with Firefox 3 Beta 5,4 etc
(In reply to comment #53) > I see this bug when deploying war files up to a tomcat server. > I am unable to do a rebuild of my application because it can not delete the > previous build. Closing Firefox, then building works. I now deploy via my build > process (Maven) I'm having exactly the same problem as moozoo.wizard@gmail.com is. After uploading a file to Tomcat the file is effectively locked until I close my browser. Closing the tab does NOT close the lock, the entire browser must be restarted.
(In reply to comment #54) > (In reply to comment #53) > > I see this bug when deploying war files up to a tomcat server. > > I am unable to do a rebuild of my application because it can not delete the > > previous build. Closing Firefox, then building works. I now deploy via my build > > process (Maven) > > I'm having exactly the same problem as moozoo.wizard@gmail.com is. After > uploading a file to Tomcat the file is effectively locked until I close my > browser. Closing the tab does NOT close the lock, the entire browser must be > restarted. I'll also add that this is for files on the same drive, no NFS, Samba, or other network shares involved.
Assignee: form-submission → nobody
Priority: P2 → --
QA Contact: ian → form-submission
Target Milestone: Future → ---
I can reproduce everytime with my Firefox 2.0.0.14 for Windows. 1. Create jpg file. 2. Go to www.tinypic.com 3. Upload your jpg file. Now you cannot delete or move the jpg file.
I am seeing this in 3.0 RC3, on Win XP. Local drive. Uploading a file to a basic PHP app (not a public site, but it's a template upload to a Joomla 1.5.3 site). I'm getting one open handle per upload, and a browser restart is required to clear the locks. Upload file sizes are 345-346 Kib.
I'll try to have a go at this. No promises though. And please please please stop the spamming. We know this bug exists, that's why it's not marked NEW rather than FIXED
Assignee: nobody → jonas
Flags: wanted1.9.1+
Priority: -- → P3
Please do not consider this as spamming, I have a hint for you: I get the same annoying problem. By disabling all Add-ons successively I have seen that only if the Live-HTTP-Headers plugin is enabled, files are locked. So maybe they do not correctly free resources.
I found that Firefox 3.0 and 3.0.1RC still has this bug where HTML form file uploading locks original file and it can't be deleted/renamed/edited until Firefox is closed. Please fix this trivial bug.
Arturs: we're accepting patches.
I can't reproduce without LiveHTTPHeaders. See https://www.mozdev.org/bugs/show_bug.cgi?id=19262 for the bug report for LiveHTTPHeaders. Anyone else able to reproduce without LiveHTTPHeaders or can we close this?
Sorry about the duplicate post, used some different keywords to search. After reading these comments I figured I also have the LiveHTTPHeaders plugin installed; disabling it solves the problem. Here's more info on the bug on the LiveHTTPHeaders bugtracker: https://www.mozdev.org/bugs/show_bug.cgi?id=19262
I was seeing this bug often with firefox 2. I have never had LiveHTTPHeaders installed. Since upgrading to firefox 3 (several months ago), I have not seen the problem once. Hence, I'm pretty certain the part of the problem that's unrelated to LiveHTTPHeaders has gone away in FF3.
(In reply to comment #68) > *** Bug 452016 has been marked as a duplicate of this bug. *** Jesse, thanks for closing my duplicate bug report, sorry for opening it but I didn't think to use "locked" as keyword when searching so I didn't find this one. And FWIW I can confirm that I also use LiveHTTPHeaders.
(In reply to comment #71) > *** Bug 454765 has been marked as a duplicate of this bug. *** Please note that this bug is a duplicate, but differs slightly from this bug description in that it happens in FF3.0.1, and closing tabs does not release the lock. The only solution is to restart FF, which is a good bit more annoying.
Verfied same problem in FF 3.0.2 after using the HTML upload function, the file never gets closed. This should be a simple io.close() command somewhere.
After uninstalling the "Live HTTP headers" Add-on the problem disappeared! I read that another user had the same solution to this problem! Using: FF 3.0.2 Windows XP SP2
It is known for a long time that this is caused by LiveHTTPHeaders : see comment 26, comment 63, comment 65, comment 69. Only comment 33 and comment 67 claim otherwise. https://www.mozdev.org/bugs/show_bug.cgi?id=19262
Does anyone have steps to reproduce the problem in Firefox 3 with a new profile (without installing LiveHTTPHeaders)? I tried the steps in bug 452952 but I could not reproduce with Firefox 3.0.3 RC on Windows XP. If we can't reproduce it without LiveHTTPHeaders, I suggest we mark this bug WFM.
(In reply to comment #76) > If we can't reproduce > it without LiveHTTPHeaders, I suggest we mark this bug WFM. Are we positive that LiveHTTPHeaders isn't exposing a Firefox bug rather than the bug being with LiveHTTPHeaders itself?
> Are we positive that LiveHTTPHeaders isn't exposing a Firefox bug rather than > the bug being with LiveHTTPHeaders itself? If it's seeking the stream after HTTP has read it, then imo yes. That said, the issue in comment 7 still needs to be looked into. Perhaps it should be spun off into a separate bug (with this one marked invalid and all the LiveHTTPHeaders dups going here, while work on the real issue that still exists happens without the ensuing noise).
> I also find it questionable that nsBufferedStream::Seek calls Fill() at all. Doesn't matter to this bug, since it's the Seek() on the file stream that reopens the file. I filed bug 459384 on the history traversal issue.
Disabling Firebug 1.30 stops this from happening for me
raised and fixed in firebug http://code.google.com/p/fbug/issues/detail?id=1374 I've not tested yet though
Resummarizing to reflect comment 7 and comment 33 so as to prevent this bug being hijacked more. Sounds like some of the recent dups marked by Matti and Natch might be different bugs altogether; I would suggest reopening them and figuring out what's going on there. Issues with Firebug and LiveHttpHeaders should probably go to separate bugs.
Summary: File upload locks file → Loading file upload result page via session history locks file
Please note that the related LiveHTTPHeaders bug at <https://www.mozdev.org/bugs/show_bug.cgi?id=19262> seems to indicate the problem does not lie entirely within that extension but also has a browser component.
Bug 479778 tracks the Firebug issue on our end, I guess.
Blocks: 479778
Blocks: 480384
OK, actually... since we do have a clean bug 459384 for the history issue, I'm just going to mark this dup of that. I should have just marked this invalid when I made comment 93, I guess. Ah, well. Please dup the LiveHttpHeaders and Firebug issues to the bugs on those respective extensions.
Status: NEW → RESOLVED
Closed: 21 years ago → 16 years ago
Resolution: --- → DUPLICATE
Isn't this backwards? Should not the newer bug report be closed as a duplicate of this older one?
Also happens on OS X, still not fixed.
Please provide detailed steps to reproduce.
Actually, seems like this bug was closed as a dupe. So if that bug is lacking steps to reproduce, please put them there instead.
The other bug seems to be an issue with history navigation, but this one requires no navigation. Just upload PDF(s) to Google Drive and all uploaded PDFs will be locked until Firefox is closed.
Please file a separate bug on that since this bug was also about navigation ("session history")
Assignee: jonas → nobody
This bug 522475 report was strictly about uploading( as described by Jerry Barler) and it got marked as a duplicate.
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.