Bug 1844663 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Steps to Reproduce:
1. Open the browser console and run:
```
let l = {}; 
XPCOMUtils.defineLazyGetter(l, "BinaryOutputStream", () => {
  return Components.Constructor(
    "@mozilla.org/binaryoutputstream;1",
    "nsIBinaryOutputStream",
    "setOutputStream"
  );
});
let file = Cc["@mozilla.org/file/local;1"].createInstance(Ci.nsIFile);
file.initWithPath("C:\\Users\\<user>\\test.txt");
let stream = FileUtils.openAtomicFileOutputStream(file);
let bstream = new lazy.BinaryOutputStream(stream);
let encoded = new TextEncoder().encode("testing 123\n");
bstream.writeByteArray(encoded);
```
2. Observe that `test.txt` exists and contains the right contents
3. Run `stream.close();`
4. Observe that `test.txt` no longer exists.

I took a peak at the implementation of `nsAtomicFileOutputStream` and noticed that the handling is a bit different if the file already exists. So I tried the above steps again after creating an existing `test.txt`. This time I see that `test-1.txt` is created with the expected output, but it is also deleted when the stream is closed and `test.txt` does not contain the new contents afterwards.

I spent a little time in a debugger investigating, and the file is being deleted [here](https://searchfox.org/mozilla-central/rev/d35b3fe3d8230a255b988afb0ebda1176fc2f50b/netwerk/base/nsFileStreams.cpp#839). It seems like it probably works properly if [`nsAtomicFileOutputStream::Finish()`](https://searchfox.org/mozilla-central/rev/d35b3fe3d8230a255b988afb0ebda1176fc2f50b/netwerk/base/nsFileStreams.cpp#847) is called first, but neither my example code nor the production code that I'm trying to fix (Bug 1830368) ever seem to hit that function.
Steps to Reproduce:
1. Open the browser console and run:
```
let l = {}; 
XPCOMUtils.defineLazyGetter(l, "BinaryOutputStream", () => {
  return Components.Constructor(
    "@mozilla.org/binaryoutputstream;1",
    "nsIBinaryOutputStream",
    "setOutputStream"
  );
});
let file = Cc["@mozilla.org/file/local;1"].createInstance(Ci.nsIFile);
file.initWithPath("C:\\Users\\<user>\\test.txt");
let stream = FileUtils.openAtomicFileOutputStream(file);
let bstream = new lazy.BinaryOutputStream(stream);
let encoded = new TextEncoder().encode("testing 123\n");
bstream.writeByteArray(encoded);
```
2. Observe that `test.txt` exists and contains the right contents
3. Run `stream.close();`
4. Observe that `test.txt` no longer exists.

I took a peek at the implementation of `nsAtomicFileOutputStream` and noticed that the handling is a bit different if the file already exists. So I tried the above steps again after creating an existing `test.txt`. This time I see that `test-1.txt` is created with the expected output, but it is also deleted when the stream is closed and `test.txt` does not contain the new contents afterwards.

I spent a little time in a debugger investigating, and the file is being deleted [here](https://searchfox.org/mozilla-central/rev/d35b3fe3d8230a255b988afb0ebda1176fc2f50b/netwerk/base/nsFileStreams.cpp#839). It seems like it probably works properly if [`nsAtomicFileOutputStream::Finish()`](https://searchfox.org/mozilla-central/rev/d35b3fe3d8230a255b988afb0ebda1176fc2f50b/netwerk/base/nsFileStreams.cpp#847) is called first, but neither my example code nor the production code that I'm trying to fix (Bug 1830368) ever seem to hit that function.
Steps to Reproduce:
1. Open the browser console and run:
```
let l = {}; 
XPCOMUtils.defineLazyGetter(l, "BinaryOutputStream", () => {
  return Components.Constructor(
    "@mozilla.org/binaryoutputstream;1",
    "nsIBinaryOutputStream",
    "setOutputStream"
  );
});
let file = Cc["@mozilla.org/file/local;1"].createInstance(Ci.nsIFile);
file.initWithPath("C:\\Users\\<user>\\test.txt");
let stream = FileUtils.openAtomicFileOutputStream(file);
let bstream = new l.BinaryOutputStream(stream);
let encoded = new TextEncoder().encode("testing 123\n");
bstream.writeByteArray(encoded);
```
2. Observe that `test.txt` exists and contains the right contents
3. Run `stream.close();`
4. Observe that `test.txt` no longer exists.

I took a peek at the implementation of `nsAtomicFileOutputStream` and noticed that the handling is a bit different if the file already exists. So I tried the above steps again after creating an existing `test.txt`. This time I see that `test-1.txt` is created with the expected output, but it is also deleted when the stream is closed and `test.txt` does not contain the new contents afterwards.

I spent a little time in a debugger investigating, and the file is being deleted [here](https://searchfox.org/mozilla-central/rev/d35b3fe3d8230a255b988afb0ebda1176fc2f50b/netwerk/base/nsFileStreams.cpp#839). It seems like it probably works properly if [`nsAtomicFileOutputStream::Finish()`](https://searchfox.org/mozilla-central/rev/d35b3fe3d8230a255b988afb0ebda1176fc2f50b/netwerk/base/nsFileStreams.cpp#847) is called first, but neither my example code nor the production code that I'm trying to fix (Bug 1830368) ever seem to hit that function.

Back to Bug 1844663 Comment 0