Sublime Forum

BUG: atomic_save breaks symbolic links!

#1

Because we’re developing variaous applications (of the same type) on a single server (Ubuntu 16.04.1 LTS), we use symbolic links to make sure all files are exactly the same.

For example: The first project is located in /usr/share/projects/project1, the second in /usr/share/projects/project2. They do different things, but both use some default functions. Therefore, /usr/share/projects/project1/assets/js/someFile.js and /usr/share/projects/project2/assets/js/someFile.js are both a symbolic link to /usr/share/projects/shared/assets/js/someFile.js. This way, we have 2 separate folders for both projects, so we can easily take it and install it somewhere else, but changes in someFile.js will take place in both projects.

We recently switched to Sublime Text, working on a single project, so in the beginning, everything looked fine. However, we recently found out that the atomic_save option, destroys all these symbolic links!

When saving someFile.js in project 2, first, the file someFile.js.tmp will be created. When written sucessfully, someFile.js will be removed and someFile.js.tmp will be renamed to someFile.js. The symbolic link is now removed and changes to someFile.js will only affect project 2.

Switching back to project 1, someFile.js here shows the ‘old’ file. So these are now different from each other. We noticed this, because my colleague started working on another project and making changes I didn’t see and vice-versa.

The atomic_save function now messed up both projects! Unfortunately, someFile.js was not the only file where this happened and we’re working on more than 2 projects. So now, we’re need to find the differences between all the files in various projects, merge them all together to a final-version in the shared-folder and recreate all symbolic links in all projects to get everything back as it was meant to be.

For now, we disabled the atomic_save function in Sublime Text (Build 3126) to prevent any more problems. But this feels like a huge bug in the atomic_save function!

0 Likes

#2

seems like something similar was reported here:

I think these days atomic_save isn’t recommended at all

0 Likes