private and readonly flags for files in .chezmoiexternal

[vbrand1984]

Hello! It would be handy if chezmoi had private and readonly optional flags for files downloaded by .chezmoiexternal alongside with the executable flag.

[twpayne]

Good idea. Implemented in #3844.

[trinitronx]

@twpayne So, I think I may have stumbled across this directory mode permission issue again on macOS and given what I've observed so far, I think may be a bug. This time, I'm using a newly installed version from Homebrew on a fresh MacBook Pro M4:

$ chezmoi version
chezmoi version v2.69.1, commit a08a575a051dbe93b9dadb63f683e437af1337ba, built at 2026-01-10T00:29:58Z, built by Homebrew

I'm currently trying to manage some other config files under ~/Library/Preferences/ as "app modified" type (symlinks to a place in Chezmoi source repo dir). These are unrelated to the Fonts in .chezmoiexternal.yaml.tmpl that I had mentioned above, but they share the parent ~/Library directory, which seems to have this weird mode bug.

However the symlinks were not being created, despite existing in the right place in the source dir:

~/.local/share/chezmoi/private_Library/private_Preferences/private_com.googlecode.iterm2.plist.tmpl

I decided to try checking the permissions on these parent dirs, and sure enough somehow on macOS the ~/Library directory had the wrong mode from running a previous chezmoi init --apply, with the ~/Library/Fonts having been installed already:

$ ls -lAd ~/Library
drwxr-xr-x@ 82 exampleuser  staff  2624 Dec 15 18:45 /Users/exampleuser/Library

$ chezmoi add ~/Library/Preferences/com.googlecode.iterm2.plist
chezmoi: mkdir /Users/exampleuser/.local/share/chezmoi/Library/private_Preferences: no such file or directory

Trying to change it back to default: 0700

$ chmod 700 ~/Library
$ ls -lAd ~/Library
drwx------@ 82 exampleuser  staff  2624 Dec 15 18:45 /Users/exampleuser/Library

$ chezmoi add ~/Library/Preferences/com.googlecode.iterm2.plist
chezmoi: mkdir /Users/exampleuser/.local/share/chezmoi/Library/private_Preferences: no such file or directory

$ chezmoi chattr +private ~/Library
chezmoi: rename /Users/exampleuser/.local/share/chezmoi/Library /Users/exampleuser/.local/share/chezmoi/private_Library: no such file or directory

Maybe somehow the "private_" prefix and mode 0700 for ~/Library got stuck in the state wrong?

So, I double check the config location in ~/.local/share/chezmoi:

$ ls -lA private_Library/private_Preferences/private_com.googlecode.iterm2.plist.tmpl
-rw-r--r--@ 1 exampleuser  staff  86 Jan 15 03:15 private_Library/private_Preferences/private_com.googlecode.iterm2.plist.tmpl

Then, I decided to check the state:

$ chezmoi state get --bucket=entryState --key=/Users/exampleuser/Library
{
  "type": "dir",
  "mode": 2147484141
}

Looks strange to me that the dir is mode: 2147484141
Meanwhile, other files mode values look to be in a much lower range (e.g. "mode": 384, "mode": 420). Maybe that's a hint at what's wrong? 🤔

I delete the state and try to re-add again:

$ chezmoi state delete --bucket=entryState --key=/Users/exampleuser/Library
$ chezmoi state get --bucket=entryState --key=/Users/exampleuser/Library
## Nothing returned this time... it's been deleted
$ chezmoi apply
Apply Library? y
diff --git a/Library b/Library
old mode 40700
new mode 40755

It still skipped the symlink for some reason, and file mode is stuck at 40755 again? Even if we take octal 0o40755 (base 8) and convert to decimal (base 10) we get 16877, not this extremely large number: 2147484141

I'm not sure how file perms are stored internally, but it does look strange to me.

Maybe there is an integer overflow somewhere in the mode handling code? Not sure if that can happen in GoLang easily. 🤷

Still trying to add or re-add the file, it goes back to Library NOT private_Library:

$ chezmoi add ~/Library/Preferences/com.googlecode.iterm2.plist
chezmoi: mkdir /Users/exampleuser/.local/share/chezmoi/Library/private_Preferences: no such file or directory

$ chezmoi re-add ~/Library/Preferences/com.googlecode.iterm2.plist
chezmoi: /Users/exampleuser/Library/Preferences/com.googlecode.iterm2.plist: not managed

At this point, I'm not sure what's going on but it won't let me manage this file with Chezmoi. I committed it to my dotfiles repo but chezmoi apply won't seem to place it. I think it has something to do with the private_Library vs. Library discrepancy with the mode value. Something is stuck where it keeps getting placed as 0755 again.

I'd love to hear what you think... maybe this is a bug, or is the 2147484141 mode really supposed to be stored that way in the state? 🤷

[trinitronx]

After experimenting a bit, I'm finding that maybe the large number in state is right?

$ mkdir  ~/foo
$ chmod 0700  ~/foo
$ touch ~/foo/bar
$ chezmoi add ~/foo/bar
$ ls -l private_foo/empty_bar
-rw-r--r--@ 1 exampleuser  staff  0 Jan 15 04:03 private_foo/empty_bar

$ chezmoi state get --bucket=entryState --key=/Users/exampleuser/foo
{
  "type": "dir",
  "mode": 2147484096
}


$ rm -rf ~/foo
$ chezmoi apply --verbose --interactive --no-pager
Apply foo?
diff --git a/foo b/foo
new file mode 40700
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
--- /dev/null
+++ b/foo
Apply foo/bar?
diff --git a/foo/bar b/foo/bar
new file mode 100644
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
--- /dev/null
+++ b/foo/bar

So 0700 became 2147484096 🤔 and in this case the private_ prefix was applied and stuck.

I checked umask on this machine and it's set to 022:

$ umask
022

Checking what 0755 turns into inside the state:

$ rm -rf ~/foo
$ mkdir ~/foo
$ chmod 0755 ~/foo
$ touch ~/foo/bar

$ rm private_foo/empty_bar
$ rmdir private_foo

$ chezmoi add ~/foo/bar
$ ls -l foo/empty_bar
-rw-r--r--@ 1 exampleuser  staff  0 Jan 15 04:15 foo/empty_bar
$ chezmoi apply --verbose --interactive --no-pager

$ chezmoi state get --bucket=entryState --key=/Users/exampleuser/foo
{
  "type": "dir",
  "mode": 2147484141
}

So we get: 0755 -> 2147484141 which I guess checks out, assuming that's what's supposed to happen for that mode. 🤷

Yet, I'm still not sure why private_Library doesn't turn into mode 0700 as usual. I'm wondering what was different about ~/Library that would do this?

So, I tried setting the mode in state to match 2147484096 in hopes that it would convert back to 0700:

$ chezmoi state set --bucket=entryState --key=/Users/exampleuser/Library --value='{ "type": "dir", "mode": 2147484096 }'

$ chezmoi apply --verbose --interactive --no-pager
## Nothing different this time, but my files under ~/Library were missing

Then, I checked .chezmoiignore again for any mention of Library. It turns out there was this:

{{- /* Different file paths for mailvelope gpgme config on Linux vs MacOS */ -}}
{{ if ne .chezmoi.os "darwin" | or (not (lookPath "gpgme-json")) -}}
Library
Library/Application Support
Library/Application Support/Mozilla
Library/Application Support/Mozilla/NativeMessagingHosts
Library/Application Support/Mozilla/NativeMessagingHosts/gpgmejson.json
{{ end -}}

So the inverted or logic was confusing, as the result is according to DeMorgan's theorem 🤦... but anyway, the stray Library inside the negated or inside a file which omits (another negation of sorts? 😮‍💨) gives us what we observe:

• When gpgme-json is not found in PATH -> Library is omitted 🤦
• When not on darwin OS -> Library is omitted 👍

So, I moved that stray Library ignore out to its own stanza:

{{ if ne .chezmoi.os "darwin" -}}
Library
{{ end -}}

Then, it works! 🎉

$ chezmoi apply --verbose --interactive --no-pager
Apply Library?
diff --git a/Library b/Library
old mode 40755
new mode 40700
Apply Library/Preferences/com.googlecode.iterm2.plist?
diff --git a/Library/Preferences/com.googlecode.iterm2.plist b/Library/Preferences/com.googlecode.iterm2.plist
new file mode 100600
index 0000000000000000000000000000000000000000..30108c8169a9e734bf278b60d0aa4802662b624b
--- /dev/null
+++ b/Library/Preferences/com.googlecode.iterm2.plist
@@ -0,0 +1 @@
+/Users/exampleuser/.local/share/chezmoi/app_modified/Library/Preferences/com.googlecode.iterm2.plist
Apply Library/Preferences/com.googlecode.iterm2.plist?
diff --git a/Library/Preferences/com.googlecode.iterm2.plist b/Library/Preferences/com.googlecode.iterm2.plist
new file mode 100600
index 0000000000000000000000000000000000000000..30108c8169a9e734bf278b60d0aa4802662b624b
--- /dev/null
+++ b/Library/Preferences/com.googlecode.iterm2.plist
@@ -0,0 +1 @@
+/Users/exampleuser/.local/share/chezmoi/app_modified/Library/Preferences/com.googlecode.iterm2.plist
Apply Library/Preferences/org.videolan.vlc?
diff --git a/Library/Preferences/org.videolan.vlc b/Library/Preferences/org.videolan.vlc
new file mode 40700
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
--- /dev/null
+++ b/Library/Preferences/org.videolan.vlc

@twpayne: Sorry for the noise... I suppose it was a complex interaction between .chezmoiignore, the double (or triple?) negative logic inside, and nested dirs underneath an accidentally ignored ~/Library. 😅

[twpayne]

macOS does a lot of weird things with the ~/Library directory. For example, since macOS 14, macOS will not follow symlinks in ~/Library directories, which completely broke mackup.

I suspect that there's more going on, but I have not investigated.

[trinitronx]

macOS does a lot of weird things with the ~/Library directory. For example, since macOS 14, macOS will not follow symlinks in ~/Library directories, which completely broke mackup.

I suspect that there's more going on, but I have not investigated.

Yeah... 😅 It turns out you were right about more going on. Except, it was actually my fault, as I found out a moment ago.

In case you missed my last edit near the end:

Sorry for the noise... I suppose it was a complex interaction between .chezmoiignore, the double (or triple?) negative logic inside, and nested dirs underneath an accidentally ignored ~/Library. 😅

[twpayne]

Ah, great! Glad that it's solved.