351551 - [SessionStore] When sessionstore.js is write-locked, a new file is created every 10 or so seconds

Status: RESOLVED FIXED

(Firefox :: Session Restore, defect)

Description

[Simon Bünzli]

Steps to reproduce:
1. Write-lock sessionstore.js (e.g. by making it read only)
2. Browse for several 10s of seconds

Actual result:
First, the file sessionstore.js.moztmp is created (inheriting the read only attribute while sessionstore.js loses it) and then subsequentially sessionstore-1.js, sessionstore-2.js, etc.

Additionally, for every sessionstore-#.js file, there's the following error in the console:

Error: Component returned failure code: 0x80520008 (NS_ERROR_FILE_ALREADY_EXISTS) [nsISafeOutputStream.finish]
Source file: file:///C:/PROGRA~1/MOZILL~2/components/nsSessionStore.js
Line: 1988

This sounds like an issue with nsISafeOutputStream (please DUPE if so), but seems not to be a purely theoretical issue (see the linked URL).

Comment 1

[Simon Bünzli]

See also bug 157152 which indicates that Spotlight might be causing this under OS X and bug 257288 which seem all to be symptoms of the same core issue.

Comment 5

[Simon Bünzli]

The issue is that once we get a write-locked .moztmp, we'll never succeed to overwrite the original (usually no longer write-locked) file.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsLocalFileWin.cpp&rev=1.170&mark=1442,1453-1456#1437

There are two possible solutions: (1) use a unique name for those temporary files instead of simply appending .moztmp or (2) make sure that either the temporary file doesn't exist or _wremove succeeds.

(1) is obviously preferred (at the cost of slightly cluttering the folder, it at least allows most calls to succeed).

Comment 6

[Simon Bünzli]

See bug 364599 where the case of read-only files was handled. Write-locking from other applications or simply denying writing permission through ACLs isn't handled at all, though.

One option would be to use nsIFile::CreateUnique or similar code to get a unique .moztmp filename (either if the original .moztmp couldn't be removed or always).

Comment 7

[Simon Bünzli]

Alright, so landing the patch to bug 368317 on the branch should in conjunction with the changes from bug 364599 fix this issue (although in the second alternative from comment #5). Additionally fixing bug 375778 should take care of the rest (preventing write-locked .moztmp files to be created at all).

Comment 8

[Daniel Veditz [:dveditz]]

If those other bugs "fix" this issue, and they are fixed on the trunk, why is this bug not fixed? Shouldn't this bug "depend on" those bugs in that case?

I'm not comfortable blocking on this unowned, apparently unfixed bug for the branch, but we'll look at the sub-bugs that have fixes.

Comment 9

[Simon Bünzli]

The issue as filed seems indeed to be fixed on trunk.