#912 Save should create+rename instead of updating in place

[Kirill Müller]

Updating in place is dangerous -- if anything serious happens while saving the file, the user is left with a corrupted file. Much safer is to write the new contents to a new file (in the same location as the target file) and renaming after writing is complete. This also resolves any potential issues with hard links (that's how I discovered this problem).

[Benito van der Zander]

Updating in place is dangerous -- if anything serious happens while saving the file, the user is left with a corrupted file. Much safer is to write the new contents to a new file (in the same location as the target file)

Right, that is an issue we need to address.

But not likely to happen

This also resolves any potential issues with hard links (that's how I discovered this problem).

But I like this how it is.

I only hard link files, if I want them to stay the same, even after one copy is edited.

[Jan Sundermeyer]

Ticket moved from /p/texstudio/bugs/1414/

[Kirill Müller]

Using hard links to files for the purpose you mentioned (ensuring file contents are the same) seems brittle to me. Links to directories are perfectly fine, but there's only soft links (or junctions on Windows) for directories.

Another possible application of hard-linking is to quickly create a snapshot of a directory tree (without actually copying the contents), to be able to work in the one directory tree without altering the contents of the other directory tree. However, this breaks if files are edited in-place.

Anyway, now that I'm aware of the behavior of TeXstudio, I can adjust mine ;-)

[Tim Hoffmann]

Some other questions that come to my mind in that context.

1. What about permissions in a write-rename pattern. I assume they are not maintained?
2. What if I have write access to the file, but not to the directory? Ok, highly unlikely, but should one consider this and fall back to a direct write?
3. One of the causes of corruption in direct write a full disk. We check for that on Windows using native API. At the time of implementation, there's been no standard way for Linux. By now has it's own abstraction Layer, so we could use that, but depends on QtMobility and I don't know, if we want that additional dependency.
4. @Benito: Why is it not likely to happen? I consider it not too complicated to implement. The only downside is that it should be tested thoroughly, which may be difficult.

[Benito van der Zander]

@Benito: Why is it not likely to happen? I consider it not too complicated to implement. The only downside is that it should be tested thoroughly, which may be difficult.

) did not mean the implementation, but that a situation where the current function loses data is unlikely

[Tim Hoffmann]

) did not mean the implementation, but that a situation where the current function loses data is unlikely

Alright. :) We would have a very big problem already if it was otherwise.

[Tim Hoffmann]

implemented: hg 5644 (c1c891d40d41)

Instead of the original proposal, I chose to copy the original file and move it back in case of an incomplete save operation. This has the advantage that we still write on the original file and thus handles cases 1. and 2. mentioned above gracefully. There's an extra cost for copying instead of renaming, but it's negligable.