👍

+1

atomic save is just not working for me on win8

Disabled on Windows.

Disabled everywhere in my opinion. On Linux, atomic save screws up group permissions.

It was actually among the first things I disabled when I switched to ST3, so I had those issues long ago and mostly forgot about them already.

I've never had issues on OSX, has anyone else?

I have only one issue on my Mac, but it's a pretty special case, still annoying. Basically we're monitoring file changes, and edits through Sublime causes excessive traffic because files are not written to per se, but instead the events generated are created -> delete org -> rename...

In all honesty, I think this feature is not useful at all (people use backups), but causes a lot of problems.

Quoting stikker from the forum:

I'd like to summarize a discussion we had internally about this issue, maybe it's useful for others:

1. On some Windows configurations, atomic saves are outright buggy and dangerous
2. On Linux, file metadata is sometimes lost (i believe this is over mounts only, but not sure)
3. On all OS's there are cases where config-directories allow edits, but not file creates (we have examples in our shop). Atomic save doesn't work at all in these cases.
4. File monitoring tools, as noted in the issue as well, depending on modify-events are confused since modify, create and delete events are all generated
5. Saving takes substantially longer over certain mounts
6. It's not a useful feature at all, the likelyhood of the rename failing during outages (esp. true on osx's fs) is higher than the likelyhood of dataloss on filewrites

Our conclusion is that not only should this feature not be default. It should not be in there at all.

Given the amount of people reporting this problem on the forums (for Windows mainly), I don't think the "minor" label does justice to this issue.

Agree.

Bumped to S: major.

Just for the record, all of those people reporting it are the same person using different user accounts. The user posts either from Tor or from a specific ISP in Norway.

@wbond on the forum? It's probably the same person who whinges about the recent development speed.

@wbond trolls aside, I believe even FichteFoll (who seems like an old-timer) mentioned on the forum he had issues with atomic save (right, Fichte?). The points mentioned by stikker above all seem valid to me.

As for the locking problem, I can easily reproduce it on a machine here, so I can upload a video of it happening if proof is needed (from a UK ip to boot...)

@JavaLama I'm not contesting that people have some issues with it, just providing information in regards to bumping is to "major" since "the amount of people reporting this problem on the forums" is not necessarily true.

@wbond Ah, fair enough. However, at least a few people have problems and let's face it: problems saving in an editor warrants the "major" label at any rate.

I think of my comment quoting stikker from the forum as the main reason for bumping the severity. It outlines how this saving mode currently has too many issues to warrant enabling it by default.

I've had several error messages from ST being unable to rename some ".tmp" file, probably because of open file handles or similar. Thus, I've disabled it and never missed it.

Yes, atomic saving might be useful in situations, but it's not a traditional way of saving in that it's in fact "renaming". The problem here is that this is not an OS-level but a software-level implementation that other software does not recognice as a "modification" so to speak. It's a feature that, if you depend on it, can still be useful as opt-in, but I doubt that it should opt-out. And, given that there's really quite some issues caused by this - not only reported by the same person -, this is an easy task that can reduce a lot of noise.

I believe issue #152 should point to #379 (this one) ?

Imo this issue should rather point to #152 since the discussion about disabling atomic_save by default is based on bugs like these, and not the other way around. But anyway, too many references don't hurt I guess. Good find btw.

If someone is using ClearCase with dynamic views, that behaviour is unacceptable - deleting the file has serious consequences related to the history tied to the object visible as file.

If anyone is using build system base on notification of changes for selected inodes, then deleting file prior to save destroy all notifications set for those inodes, as you crate new inode every time.

On filesystems like ZFS, where you can maintain changes or snapshots to files stored, deleting the file and creating it again to save would destroy the history of the inode and you'll see now files between snapshots - I don't believe this is what you want.

On NAS storages which serve Samba shares, deleting a file means that when replication happens, the file is deleted on all nodes taking part in replication, and then when new file is saved - whole file has to be transmitted during replication process. What a huge waste of expensive resources for a change containing single space character of difference.

This is just couple example why such feature should never exists. I vote for complete removal of this "atomic" writes.

Another atomic_save bug appeared as webdav failures: http://www.sublimetext.com/forum/viewtopic.php?f=3&t=16586

+13453. I wasted hours of NFS problems because of that. Fix it or disable it by default.

Added an atomic save category and relabeled issues.

+1, there a bug with atomic_save and vagrant.

http://stackoverflow.com/questions/23817843/files-dont-update-in-vagrant-when-saved-on-host-computer

+1, still getting this error with atomic_save: false, using ST3 build 3065

Thanks for any help.

Which error and why would "atomic_save": false solve it (this issue is about the exact opposite)?

I arrived at this issue from reading here, https://www.sublimetext.com/forum/viewtopic.php?f=2&t=16519.

"This is a known bug that hit me as well: #379

Unfortunately, this is an issue tracker that is not currently tracked by the Sublime Text developer (but may be at a later point IIRC)

I would encourage you to shoot a mail to sublimetext hq - a lot of people are having this issue so it doesn't hurt that they get some mails regarding the issue."

I intermittently receive this error (unable to save, the process cannto access the file because it is being used by another process) when saving a file, in my case a typescript file, on the same system as the original poster in that previous thread. That is why I originally responded to this thread. I will respond to the other thread.

Thanks.

Judging by your forum post, the issue with atomic_save: false seems to be similar to #701 or the same. If you are not using the latest dev build, please try that and see if it was fixed.

I've seen your problem with atomic_save: true before too, but can't find it in the issue list. It's likely a new issue, so please open a new one.

Thanks. I will try the latest build and see if I can repro.