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