Sublime Forum

[ST3/Linux] New files are created world-writable


Using Sublime Text build 3047, all newly created files are world-readable and world-writable (rw-rw-rw-), even though my umask is set to 0077. Opening and saving an existing file preserves permissions as usual. I tried querying the current umask from the Python console using os.umask(), which returned 0, so I assume that ST3 somehow resets its umask at startup? (I also tried changing the “atomic_save” setting to false, but this had no effect.)

I only recently upgraded to Sublime Text 3 Beta - I haven’t noticed this problem with ST2. I have found one other thread that may be related to this problem.

Is there a way to work around this issue (other than manually changing file permissions), or perhaps a configuration setting I can change?



Dev Build 3073

Thanks for the report - we’ll get this fixed for the next build. However, it should only be occurring when atomic_save is enabled.



You are right. I tried setting atomic_save to false before, but I didn’t restart the editor. After a restart with atomic_save = false, the issue is gone.




I am having this same problem. I have set atomic_save to false in my User/Preferences.sublime-settings file, restarted ST3, restarted my computer, and yet every time I create a folder or file from within ST3, the file has permissions wide-open. This is causing some problems in my workflow, as tools important to my ability to develop require the directory they operate on to have file permissions of either 755 or 775. So I’m working around it by making sure I create all folders and files first, and then open them in sublime, but this is definitely not how I prefer to work. I’ve been a long time fan of Sublime, and encouraged a number of my friends and colleagues to switch over, created multiple plugins, etc. but this is a real problem with serious implications, so I really hope getting it fixed is a high priority. I know you said it will be fixed in the next build. @jps Is there any idea how far off that is? I want to remain on 3, because it really is a huge improvement over 2, which was already an amazing editor.

If It helps I am currently on Ubuntu. These are the packages I have installed:

                    "Better CoffeeScript",
                    "Color Scheme - saulhudson",
                    "Enlightened Color Scheme",
                    "Git Config",
                    "Local History",
                    "Package Control",

I have tried disabling all of them, with no change. Thanks for all your hard work, I’m sure you will get this sorted out quickly.



purchased a license, installed latest dev build, and I can verify this does fix the issue.



The umask bug is back in 3052, today.

lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch:trialuse-4.1-amd64:trialuse-4.1-noarch
Distributor ID: Fedora
Description: Fedora release 19 (Schrödinger’s Cat)
Release: 19
Codename: Schrödinger’sCat

python --version
Python 2.7.5



I can also confirm that my original issue is back in build 3052.



It seems that this issue hasn’t been fixed completely in the latest build 3053, but it has gotten more complicated. It now depends on the way Sublime Text is started, but I don’t understand how or why.

The simplest reproducable case goes like this:

  1. Open a terminal window, and make sure that no Sublime Text process is already running.
  2. Verify that the umask in the shell is set to 0077.
  3. Start “subl”.
  4. Create a new file by entering some text, then save.
  5. The new file has permission “rw-rw-rw”.

However, and this is where things get strange, if I start Sublime Text through some kind of desktop launcher (I’m using Kupfer), and repeat the exact same steps, the new file has the correct permissions “rw-------”. I initially suspected that the umask of the launching process might be different, but as far as I can tell the umask is always 0077 right before Sublime Text is started.

I did some additional testing with strace, and it seems that Sublime Text sets its own umask to 000 at some point during the launch:

$ strace -e umask -f subl Process 12431 attached [pid 12431] umask(0) = 077 ...

That output also suggests that the original umask was indeed 077.



In my case, no matter the way I use to launch the app, the permissions are wrong (-rw-rw-rw-). umask in terminal is 0002, happens if I launch from terminal but also if I launch from Unity. I have set the atomic_save option to false and am running build 3059 on Ubuntu 13.10 64 bits.



Just for information: I saw that build 3061 has the same bug.



This bug is still present in build 3062.

Just to mention the bug in bug bugtracker: