We use Sublime Text with emmet and it works great for the most part. Absolutely stunning editor!

Unfortunately, a few of our programmers experience problems when saving. Occasionally when saving, a “file locked” error pops up and sometimes it’s impossible to save so unless they copy/paste into another editor, the content is lost. On one machine where this happens, we could reproduce it easily in Sublime, but could not reproduce it in Notepad (same file)

Is this a known problem/is it being worked on? Most of us run the very latest beta on Windows and Mac.

Disable “atomic_save”. It causes a variety of issues and is only a bonus anyway.

Thanks, I’ll shoot this tip out on our internal mailing list and see if that sorts it out.

EDIT: This indeed seems to solve the save issue. Thank you FichteFoll!

[quote=“aquit”]

Thanks, I’ll shoot this tip out on our internal mailing list and see if that sorts it out.

EDIT: This indeed seems to solve the save issue. Thank you FichteFoll!

So it’s an editor that’s by default unable to save? Amusing.[/quote]

Heh, there’s actually some truth to this, on at least one of our Windows machines. The lock message consistently prevents the file from being saved from the get-go.

I would strongly suggest to Sublime Text HQ that “atomic_save: false” is the default on Windows.

[quote=“stikker”]
Heh, there’s actually some truth to this, on at least one of our Windows machines. The lock message consistently prevents the file from being saved from the get-go.

I would strongly suggest to Sublime Text HQ that “atomic_save: false” is the default on Windows.[/quote]

I think I’ve mentioned before that I hate these kinds of issues. I’ve been trying to reproduce atomic save issues, and I have been unable to do so. So the threads on this issue end up in a “works for me” loop.

[quote=“ntenney”]

[quote=“stikker”]
Heh, there’s actually some truth to this, on at least one of our Windows machines. The lock message consistently prevents the file from being saved from the get-go.

I would strongly suggest to Sublime Text HQ that “atomic_save: false” is the default on Windows.[/quote]

I think I’ve mentioned before that I hate these kinds of issues. I’ve been trying to reproduce atomic save issues, and I have been unable to do so. So the threads on this issue end up in a “works for me” loop.[/quote]

And “works for me” is never a useful reply, but you seem to be doing it a lot.

I’ve searched the forum and this is an issue for quite a few people and while I have no idea what the conditions for trigging this bug are, until it’s resolved, I strongly object to having atomic_save on by default on Windows.

FYI, added this: github.com/SublimeText/Issues/issues/379

Hopefully it will be handled before 3.0 stable.

[quote=“FichteFoll”]FYI, added this: github.com/SublimeText/Issues/issues/379

Hopefully it will be handled before 3.0 stable.[/quote]

I just found github.com/SublimeText/Issues/issues/373

Maybe the two issues should be merged

I’ve closed #373 in favour of #379

Thanks, hopefully HQ reads through the issues

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.

[quote=“stikker”]
And “works for me” is never a useful reply, but you seem to be doing it a lot.

I’ve searched the forum and this is an issue for quite a few people and while I have no idea what the conditions for trigging this bug are, until it’s resolved, I strongly object to having atomic_save on by default on Windows.[/quote]

Perhaps I should have been more clear. When I’ve said I don’t see that error, it’s not to discount that the problem exists, just that on my configuration I haven’t experienced it. I am actively trying to reproduce this particular error. Every time I’ve asked for more information on configurations to try to reproduce this error, the thread goes dead. Since you and several people at your location have experienced this bug, perhaps you can answer my questions about your setup. I can test on a variety of platforms, I use Sublime on Windows, Linux, and Mac. I’m going to use your later post as a text for my questions.

1. Is there anything you’ve noticed about atomic save on windows that allows you to reproduce save problems consistently?
   a. What anti-virus programs are installed on your windows machines
   b. Are you using any programs that monitor file state (such as TortiseSVN/TortiseHG, etc…), or programs that watch directories to perform automatic builds (I’m guessing from your statement 4 that you are using something like that)?
2. On Linux, what file metadata is lost?
3. On OS’s where the config directories don’t allow creates, can you look at the directory permissions? If so, what are they?
4. By mounts, what do you mean? Are you speaking of NFS/samba served file systems?
5. Can you recreate the issue on OSX where a rename fails? Do you have a set of steps that could be used to reproduce the issue?

I don’t doubt the issue exists, and I’m not trying to disprove anyone. What I’m trying to do is help come up with a consistent way to reproduce the issue so that it can be easier to fix when Jon goes to fix it. If we can come up with a set of steps to reproduce the errors consistently, it will be easier to fix, and to verify that it is fixed.

[quote=“ntenney”]

I can understand why the thread goes dead, because it’s only Sublime HQ that can fix the error, hence only their request for information is sensible to spend time on.

That said:

There’s a bunch of people involved in the summary previously in this thread. I’ve asked for more information, but here is what I do know:

1a) none on at the machine i watched it happen on, b) some are, some are not.
2) group permissions, time created (this should be retained). Happens on 3.x kernels, fedora.
3) quite simply that files can be modified, but not created. This is a no-brainer and “by design”, but another reason why atomic save is bad.
4) nfs
5) it’s an inherit weakness in the file system, but now you’re in the realms of probability (which was our original point)

I think our main message is that it’s senseless to spend time on fixing this feature, since it’s not useful. Just nuke it.

I think the concept behind atomic saves is logical. If something goes sideways when saving a file, you don’t lose both the old and new versions. I imagine it is most useful to people who don’t use version control, so turning it off by default would probably not benefit many people. The majority of people who would benefit from it are not the type to go exploring all of the available settings to enable it.

On the other hand, it seems by-in-large, it is a much smaller percentage of people who have issues with it. Obviously bugs that can be fixed should. I can’t image it will ever work for everyone. According to sublimetext.com/3dev, it should dynamically disable itself on OS X and Linux when it can’t be used. It sounds like while some permissions issues have been resolved, group permissions should be fixed also. I suppose some permissions issues on Linux may not be possible to preserve due to owner/group changes and not being able to chown a file to a different user.

Perhaps it could make sense to have some sort of first-run dialog with Sublime where users would pick certain settings? Other solutions could include better documentation of the possible side-effects so that users can figure out what is going on via Google.

[quote=“wbond”]

I think the concept behind atomic saves is logical. If something goes sideways when saving a file, you don’t lose both the old and new versions.[/quote]

The problem with the logic is that the probability of this happening is about as low as something going sideways when doing the tmp/rename/delete cycle (which involves a lot of inode activity). This combined with the amount of problems makes it a rather dubious feature.

This is most definitively not the case on fedora. And it’s not like it’s a small issue either - I’m sure you can envision what might happen when doing a stop-the-fire editing of a core config file in production and the permissions are suddenly changed. No editor should ever do anything remotely like that.

The number of issues reported on the forums is large enough, and I imagine there’s a substantial amount of people seeing this on first try and then never use sublime again (and don’t report it.)

And I seriously doubt anyone has actually benefited from this feature and ever will.

[quote=“stikker”]

This is most definitively not the case on fedora. And it’s not like it’s a small issue either - I’m sure you can envision what might happen when doing a stop-the-fire editing of a core config file in production and the permissions are suddenly changed. No editor should ever do anything remotely like that.[/quote]

I should rephrase: Sublime Text should be fixed so it properly writes group permissions. I think we are in agreement here.

I tend to doubt that out of the millions of users of Sublime Text that no one has ever benefited from atomic saves. I’m not here to argue with you, I’m just giving you (and other forum visitors) an alternative viewpoint.

I’m not here to argue either, just to inflict some common sense.

Numbers talk. Numerous reports of problems, no reports of usefullness.

Billions of users use text editors without atomic save, and how many times does saving a file in those fail? The few cases where there’s a problem, it’s likely to be FS corruption or disk failure, at which point the tmp/del/rename dance makes things even worse on some file systems.

And at any rate, it’s illogical to replace straight saves with an even more fragile mechanism. The correct way is to do raid, backups, whatnot, not using an editor playing stupid tricks that causes problems.

I’m +1 here. Seems like atomic save is a solution in search of a problem, causing real problems.

At least implement it correctly, using shadow copies on Windows, lvm snapshots on linux when available, etc.

People are much more likely to complain about stuff that doesn’t work than to praise for things that did. I mean, after all you expect a product to be working, so it working is the normal case here.