[help] each time install dotfiles ask chmod them to 644 in WSL

[roachsinai]

I'm using dotdrop in WSL and using it manage dotfiles both Linux side and Windows side. After I upgrade dotdrop to lastest version each time I run dotdrop install will get below extra confirm:

As these files are installed to Windows side the chmod command is useless for them, so dotdrop will ask each time I run install.

---

I've used force_chmod:

config:
  force_chmod: true

But seems not work.

---

How to set dotdrop just copy dotfiles to destination if I doesn't specific 644s in conf.yaml like previous version?

Thansk!

[deadc0de6]

Thanks for reporting this. Which version are you using (as a submodule or something else)?

I refactored how force_chmod is handled in branch 429, can you give it a try?

[roachsinai]

I'm using https://aur.archlinux.org/packages/dotdrop , force_chmod worked by update PKGBUILD to source=("git+https://github.com/deadc0de6/dotdrop.git#branch=fix-428"), thanks for that!

But from my point of view, if I don't set force_chmod in global yaml nor specific dotfile entry, dotdorp should just copy managed dotfiles to destination like command cp and dotdrop previous version.

[deadc0de6]

Awesome, I'll merge the change of branch 429 in master. It will be available in the next version of dotdrop.

The permissions doc provides a description of the behavior of dotdrop regarding permissions. What are you currently using? (preserve, no chmod entry, etc) and where are you having issues?

[roachsinai]

Hi, I found it only happend when install a directory entry (dst to WSL):

  d__snip:
    src: vim/snip
    dst: /mnt/c/Users/xq/vimfiles/snip
    chmod: '777'

hwin ~ » dpin -p wsl-win
        -> chmod /mnt/c/Users/xq/vimfiles/snip/cpp.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/ps1.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/markdown.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/python.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/dosbatch.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/cmake.snippets to 644
        -> chmod /mnt/d/Scoop/persist/mpv/portable_config/input.conf to 644
        -> chmod /mnt/d/Scoop/persist/mpv/portable_config/scripts/last.lua to 644
        -> chmod /mnt/d/Scoop/persist/mpv/portable_config/mpv.conf to 644
        -> chmod /mnt/c/Users/xq/vimfiles/ftplugin/make.vim to 644
        -> chmod /mnt/c/Users/xq/vimfiles/ftplugin/python.vim to 644
        -> chmod /mnt/c/Users/xq/vimfiles/ftplugin/c.vim to 644
        -> chmod /mnt/c/Users/xq/vimfiles/ftplugin/cpp.vim to 644

Get below output after remove chmod: '777' (check the 755 below):

hwin ~ » dpin -p wsl-win
        -> chmod /mnt/c/Users/xq/vimfiles/snip/cpp.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/ps1.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/markdown.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/python.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/dosbatch.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip/cmake.snippets to 644
        -> chmod /mnt/c/Users/xq/vimfiles/snip to 755
        -> chmod /mnt/d/Scoop/persist/mpv/portable_config/input.conf to 644
        -> chmod /mnt/d/Scoop/persist/mpv/portable_config/scripts/last.lua to 644
        -> chmod /mnt/d/Scoop/persist/mpv/portable_config/mpv.conf to 644
        -> chmod /mnt/c/Users/xq/vimfiles/ftplugin/make.vim to 644
        -> chmod /mnt/c/Users/xq/vimfiles/ftplugin/python.vim to 644
        -> chmod /mnt/c/Users/xq/vimfiles/ftplugin/c.vim to 644
        -> chmod /mnt/c/Users/xq/vimfiles/ftplugin/cpp.vim to 644

[deadc0de6]

As mentioned in the doc, when chmod is defined, it will be applied to the dotfiles. I'm guessing your umask value is 022 (you can get that, at least on linux, with the command umask).

This is what you see on your first example with chmod: '777'. I'm guessing the /mnt/c/Users/xq/vimfiles/snip directory gets a permission value of 777 while its files get the system default permission (666 - <umask>). With a umask of 022 it gives you the 644 you are seeing.

Regarding your second example (without the chmod: '777') then files get 666-<umask> and directory 777-<umask>, therefore the snip directory gets 777 - 022 = 755.

Since the dotfile defines the permission for the directory but not for the individual files inside it, all those files will get the default system permission (666-<umask>). If you want to control each file permission you have to define a dotfile per file or have an action that would alter permissions after their installation.

[roachsinai]

Thanks for explanation! Sorry for thought chmod is recursively. But this happend after update dotdrop.