Open Bug 518012 Opened 15 years ago Updated 2 years ago

Saving pages to disk should not lock the HTML and directory together

Categories

(Firefox :: File Handling, defect)

x86
Windows Server 2003
defect

Tracking

()

REOPENED

People

(Reporter: glenn, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) When a page is saved as "Web Page, complete", it saves the page (filename.htm) and the contents (filename_files). For some reason, it's using an obscure Windows API to lock these files together. This is very bad: deleting one of these two causes both to be deleted, without any explanation, warning or confirmation. Nobody expects deleting one file or directory to implicitly delete another one. Reproducible: Always After I've saved a webpage to a file and spent quite some time editing that page (typically to narrow down a rendering bug), it leaves the directory unused, since I'll remove any references to it to get a self-contained repro case. Since I don't need the directory anymore, I delete it--and suddenly the repro case I just made is mysteriously gone, too. If I didn't happen to still have an editor open on the file I'd have lost it completely. I don't even know what Windows calls this "feature", and nothing else I've ever seen uses it. It is dangerous and should not be used.
That is actually something in windows. Not sure where it is found (somewhere in folder options I think), but you can select to move connected files and folders as a unit. Ah, I think Tweak UI (not sure if you can use it for 2003) can do this changing. This page, http://www.tomshardware.com/forum/58027-45-files-saved-folders-icons, has some info that may help.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
By the time anyone finds out that they need to do that, they'll already have lost data. Only by luck did I avoid it. Telling people how to work around strange behavior after it's already bitten them isn't very helpful; Firefox should not be triggering this to begin with. I think just using a different name for the directory (remove "_files"; that's cleaner anyway) will prevent this behavior. This is clearly being triggered intentionally by Firefox (due to the specific choice of filenames), and it shouldn't be; it's dangerous and evil. This seems to happen in embedding/qa/testembed/BrowserView.cpp in CBrowserView::OnFileSaveAs(). "Connecting Files" in http://msdn.microsoft.com/en-us/library/bb762164%28VS.85%29.aspx explains the filename rules that trigger this.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Please reopen the bug if you still reproduce the issue.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago11 years ago
Resolution: --- → WORKSFORME
I report an issue. It gets ignored for four whole years. The issue still occurs, completely unchanged, then the bug is closed as "works for me". As have doubts that you even tried to reproduce it, since it's so trivial to reproduce (file -> save as; page is saved as "page.htm" and "page_files"). This is why I stopped reporting bugs in Firefox. If you're going to ignore bugs, then don't waste our time having a bug tracker in the first place.
Reopening per comment 4.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.