Notepad++ resets file permission bits for WSL files on save
-
Thanks all for thoughts and suggestions. One thing I mentioned in my question seems to have been overlooked:
- These scripts are located on Windows file system and I access them via /mnt/d/…
WSL allows to mount regular windows drives to /mnt/c, /mnt/d, … :
$ mount | grep -e "/mnt/[cd]" C:\ on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;umask=22;fmask=111;metadata;case=off;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=3,wfd=3) D:\ on /mnt/d type 9p (rw,noatime,dirsync,aname=drvfs;path=D:\;uid=1000;gid=1000;umask=22;fmask=111;metadata;case=off;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=3,wfd=3)
So, no need for \wsl$… really to access these files. They reside somewhere blow D:… in my case here.
And I start these scripts from within wsl. (/mnt/d/…/myscript.sh)
Maybe this helps for better understanding and problem solving. Maybe the API calls npp uses to access files mangels with the attributes set from within wsl as @mkupper already mentioned.
-
@mkupper said in Notepad++ resets file permission bits for WSL files on save:
@anno73 said in Notepad++ resets file permission bits for WSL files on save:
Whenever I now save a script in npp, the executable bit gets cleared.
Can you confirm this?
- Start Notepad++
- From within wsl inspect the file’s permissions using
ls -l
to confirm that the x or execute bit is on.
$ cd /mnt/d $ echo Hello > test.sh $ ls -l test.sh -rw-r--r-- 1 u g 6 Nov 6 13:56 test.sh $ chmod +x test.sh $ ls -l test.sh -rwxr-xr-x 1 u g 6 Nov 6 13:56 test.sh*
- From Notepad++ open the file - don’t make any changes. Just open it.
- From within wsl inspect the file’s permissions using
ls -l
to confirm that the x or execute bit is on.
$ ls -l test.sh -rwxr-xr-x 1 u g 6 Nov 6 13:56 test.sh*
- From Notepad++ change one letter in the file. Don’t save it yet. We just want the Notepad++ tab for the file to now be red.
- From within wsl inspect the file’s permissions using
ls -l
to confirm that the x or execute bit is on.
$ ls -l test.sh -rwxr-xr-x 1 u g 6 Nov 6 14:05 test.sh*
- From Notepad++ do
Ctrl+S
to save the file. Don’t close the tab yet. - From within wsl inspect the file’s permissions using
ls -l
to confirm that the x or execute bit is on.
$ ls -l test.sh -rw-r--r-- 1 u g 7 Nov 6 14:10 test.sh
- From Notepad++ do
Ctrl+W
to close the tab. - From within wsl inspect the file’s permissions using
ls -l
to confirm that the x or execute bit is on.
$ ls -l test.sh -rw-r--r-- 1 u g 7 Nov 6 14:10 test.sh
- From Notepad++ do
ALT+F4
to close/exit Notepad++ - From within wsl inspect the file’s permissions using
ls -l
to confirm that the x or execute bit is on.
$ ls -l test.sh -rw-r--r-- 1 u g 7 Nov 6 14:10 test.sh
Did the x or execute bit get turned off anywhere in those steps? If so, what step?
Following directions from above, the executable bits were removed upon save.
I also tried to edit the file via opening
\\wsl$\Debian\d\test.sh
in npp, but this got prevented by a windows access denied error to mountpoint directory d.When editing
\\wsl$\Debian\home\user\test.sh
the executable bits are not reset. -
Out of curiosity, I also tried VSCode. The bits did not change upon save. The script stayed executable.
-
Thanks for the details and the
ls -l
test. Now I see where the problem is (probably - I did not have time to setup a WSL test & debug that in N++ yet).The problem is really in what I already stated (a possibility that N++ uses in this case incorrectly the
CREATE_ALWAYS
file saving disposition parameter somehow instead of theTRUNCATE
one). My mistake was in the wrong assumption, how the storage of such WSL Linux permissions is implemented on the Windows side in NTFS - I thought it would be the NTFS Alternate Data Streams (this is already covered in the N++ file saving code) but it is implemented via the Extended Attributes (ref.).So the fix should be easy - adding one more pre-check for the
FILE_ATTRIBUTE_EA
. I will see what I can do but please be patient, nowadays I have almost no free time… -
Thanks for having a look at the issue.
I just remembered, I am using 32bit version of npp. So I tested the 64bit version too: There it works as expected. Executable bit is there after saving the file. Hope this gives you some more hints.
-
@anno73 said in Notepad++ resets file permission bits for WSL files on save:
Hope this gives you some more hints.
Actually, now it is more confusing to me ;-)
So maybe my EA theory is wrong.I still cannot debug the issue because my current WSL installation just seems to have all gates up for the NTFS file-permissions (every file has all the permissions and the chmod cannot change anything, I probably have the NTFS drive mounted differently than you or setup somehow without the EA…)
-
LOL
I have following entries in my /etc/fstab:
C:\ /mnt/c drvfs rw,noatime,uid=1000,gid=1000,umask=22,fmask=111,metadata,case=off D:\ /mnt/d drvfs rw,noatime,uid=1000,gid=1000,umask=22,fmask=111,metadata,case=off
and this is /etc/wsl.conf:
[boot] systemd = true [automount] enabled = true options = "metadata,umask=22,fmask=111" [network] generateResolvConf = true [interop] enabled = true
I am not sure if anything else affects the file system mount logic in wsl.
-
Thanks, with the updated wsl.conf, it is ok now.
But I cannot reproduce your problem, my N++ (both 64- and 32-bit) does not mangle/delete the EA set by the
chmod
on save:I am even able to see, what the
chmod +x
command really does on the NTFS drive (EA) and the N++ does not change this: -
@xomx
I’m not sure if this helps.
I’m getting the same problem with the 64bit version of NPP version 8.5.7, when using NPP in windows to edit a file on a RHEL linux server over SSH (via mobaxterm).
Instead of the execute permissions being removed, rather NPP is saving all files with 644 permissions.
Which means no execute permissions in this case.
eg.chmod 750 test.sh -rwxr-x--- test.sh
when script is saved
test.sh
becomes-rw-r--r-- test.sh
-
@Liming-Tieu said in Notepad++ resets file permission bits for WSL files on save:
I’m getting the same problem with the 64bit version of NPP version 8.5.7
If you can, please 1st upgrade to the latest upcoming v8.7.5 (in the current v8.7.4 is a critical regression, it will be replaced by v8.7.5 soon). Why - there are many fixes which are related to this area, specifically - the next version from the yours (v8.5.8) fixed the overwriting of some NTFS metadata (“Fix saving files losing Alternate Data Stream issue. (Fix #1498, #8451, #8013)”).
(here you will find a convenient overview of all the changes in N++ versions: https://github.com/notepad-plus-plus/notepad-plus-plus/wiki/Changes )
Then please report back here, if your problem persists.