starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[BUG]: Komorebic is not able to load configuration symlinked from WSL. #393

New Issue
Closed
opened 2026-01-05 14:50:20 +01:00 by adam · 3 comments
adam commented 2026-01-05 14:50:20 +01:00
Owner
Copy Link

Originally created by @ferdinandyb on GitHub (May 28, 2024).

Describe the bug

Komorebic is not able to load configuration symlinked from WSL.

To Reproduce

Symlink the .config/komorebi directory to WSL, with mklink /D komorebi \\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\komorebi

The result should be something like this:

PS C:\Users\bferdinandy\.config> dir . -recurse -force | ?{$_.LinkType} | select FullName,LinkType,Target

FullName                              LinkType     Target
--------                              --------     ------
C:\Users\bferdinandy\.config\komorebi SymbolicLink {UNC\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\komorebi}
C:\Users\bferdinandy\.config\whkdrc   SymbolicLink {UNC\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\whkdrc}


PS C:\Users\bferdinandy\.config> dir \\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\komorebi


    Directory: \\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\komorebi


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
------     2023. 03. 28.     16:44          19296 komorebi.generated.ps1
------     2024. 05. 28.     11:10          29380 applications.yaml
------     2024. 05. 28.     11:28           1482 komorebi.json
------     2023. 03. 28.     16:45           1588 komorebi.ps1

Run komorebi.exe and see that komorebi cannot open the configuration file:

PS C:\Users\bferdinandy\.config> komorebi.exe
2024-05-28T09:46:40.043792Z  INFO foreground_lock_timeout: komorebi::windows_api: current value of ForegroundLockTimeout is 0
2024-05-28T09:46:40.059426Z  INFO komorebi: creating window manager from static configuration file: C:\Users\bferdinandy\.config\komorebi\komorebi.json
Error:
   0: The system cannot find the file specified. (os error 2)

Location:
   komorebi\src\static_config.rs:618

Note that cat C:\Users\bferdinandy\.config\komorebi\komorebi.json will output the file, although it does take around 3 seconds.

Expected behavior

Komorebi reads the configuration file properly.

Operating System
Provide the output of systeminfo | grep "^OS Name\|^OS Version"

OS Name:                   Microsoft Windows 11 Enterprise
OS Version:                10.0.22631 N/A Build 22631

komorebic check Output
Provide the output of komorebic check

PS C:\Users\bferdinandy\.config> komorebic check
KOMOREBI_CONFIG_HOME detected: C:\Users\bferdinandy\.config\komorebi

Looking for configuration files in C:\Users\bferdinandy\.config\komorebi

Found komorebi.json; this file can be passed to the start command with the --config flag

Application specific configuration file path 'C:/Users/bferdinandy/applications.yaml' does not exist. Try running 'komorebic fetch-asc'

Found C:\Users\bferdinandy\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
Originally created by @ferdinandyb on GitHub (May 28, 2024). **Describe the bug** Komorebic is not able to load configuration symlinked from WSL. **To Reproduce** Symlink the `.config/komorebi` directory to WSL, with `mklink /D komorebi \\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\komorebi` The result should be something like this: ``` PS C:\Users\bferdinandy\.config> dir . -recurse -force | ?{$_.LinkType} | select FullName,LinkType,Target FullName LinkType Target -------- -------- ------ C:\Users\bferdinandy\.config\komorebi SymbolicLink {UNC\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\komorebi} C:\Users\bferdinandy\.config\whkdrc SymbolicLink {UNC\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\whkdrc} PS C:\Users\bferdinandy\.config> dir \\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\komorebi Directory: \\wsl.localhost\Ubuntu\home\bferdinandy\.config\wsl\komorebi Mode LastWriteTime Length Name ---- ------------- ------ ---- ------ 2023. 03. 28. 16:44 19296 komorebi.generated.ps1 ------ 2024. 05. 28. 11:10 29380 applications.yaml ------ 2024. 05. 28. 11:28 1482 komorebi.json ------ 2023. 03. 28. 16:45 1588 komorebi.ps1 ``` Run `komorebi.exe` and see that komorebi cannot open the configuration file: ``` PS C:\Users\bferdinandy\.config> komorebi.exe 2024-05-28T09:46:40.043792Z INFO foreground_lock_timeout: komorebi::windows_api: current value of ForegroundLockTimeout is 0 2024-05-28T09:46:40.059426Z INFO komorebi: creating window manager from static configuration file: C:\Users\bferdinandy\.config\komorebi\komorebi.json Error: 0: The system cannot find the file specified. (os error 2) Location: komorebi\src\static_config.rs:618 ``` Note that `cat C:\Users\bferdinandy\.config\komorebi\komorebi.json` will output the file, although it does take around 3 seconds. **Expected behavior** Komorebi reads the configuration file properly. **Operating System** Provide the output of `systeminfo | grep "^OS Name\|^OS Version"` ``` OS Name: Microsoft Windows 11 Enterprise OS Version: 10.0.22631 N/A Build 22631 ``` **`komorebic check` Output** Provide the output of `komorebic check` ``` PS C:\Users\bferdinandy\.config> komorebic check KOMOREBI_CONFIG_HOME detected: C:\Users\bferdinandy\.config\komorebi Looking for configuration files in C:\Users\bferdinandy\.config\komorebi Found komorebi.json; this file can be passed to the start command with the --config flag Application specific configuration file path 'C:/Users/bferdinandy/applications.yaml' does not exist. Try running 'komorebic fetch-asc' Found C:\Users\bferdinandy\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag ```
adam added the bug label 2026-01-05 14:50:20 +01:00
adam closed this issue 2026-01-05 14:50:20 +01:00
adam commented 2026-01-05 14:50:20 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (May 28, 2024):

https://github.com/microsoft/WSL/issues/5118

Possibly related to the issue above, but even if it's not I have no intention of touching this and will not accept any patches that try to implement any workarounds; the maintenance burden on something this brittle just isn't worth it.

I keep all of my dotfiles, including my Windows dotfiles, including my komorebi.json file, in my NixOS configuration. The sane move here to copy-on-change across the network mount and not to try to symlink.

@LGUG2Z commented on GitHub (May 28, 2024): https://github.com/microsoft/WSL/issues/5118 Possibly related to the issue above, but even if it's not I have no intention of touching this and will not accept any patches that try to implement any workarounds; the maintenance burden on something this brittle just isn't worth it. I keep all of my dotfiles, including my Windows dotfiles, including my komorebi.json file, in my NixOS configuration. The sane move here to copy-on-change across the network mount and not to try to symlink.
adam commented 2026-01-05 14:50:20 +01:00
Author
Owner
Copy Link

@ferdinandyb commented on GitHub (May 28, 2024):

Yeah, my dotfiles are also in WSL with yadm. Copying is of course a viable option, so I can live with this.

@ferdinandyb commented on GitHub (May 28, 2024): Yeah, my dotfiles are also in WSL with yadm. Copying is of course a viable option, so I can live with this.
adam commented 2026-01-05 14:50:20 +01:00
Author
Owner
Copy Link

@tpsteiner commented on GitHub (Apr 22, 2025):

For me too. Not a big deal. It might be a nice-to-have in the future. I use chezmoi to manage my dotfiles. It's awesome. On a related note: XDG compliance would also be nice, though doing so will screw up everyone's current config xD

Solution to copy on apply for chezmoi, courtesy of Gemini...

# ~/.config/chezmoi/chezmoi.toml
[data]
    windows_username = "Tom" # Replace "Tom" with your actual Windows username

Paste the following into ~/.local/share/chezmoi/run_after_99-sync-komorebi-to-windows.sh.tmpl

#!/bin/bash
# vim: set ft=sh:

# Exit immediately if a command exits with a non-zero status.
set -e

# Define the source directory (where chezmoi puts the files in WSL)
# Assumes standard chezmoi behavior placing dot_config/komorebi into ~/.config/komorebi
WSL_SOURCE_DIR="$HOME/.config/komorebi"

# --- Define the target directory on the Windows filesystem ---
# Use the windows_username from chezmoi's config data
WINDOWS_USER="{{ .windows_username }}"
# Construct the WSL path to the Windows target directory
WINDOWS_TARGET_DIR="/mnt/c/Users/$WINDOWS_USER/.config/komorebi"
# --- End target directory definition ---


# Ensure the source directory exists (it should if chezmoi managed files there)
if [ ! -d "$WSL_SOURCE_DIR" ]; then
    echo "Source directory $WSL_SOURCE_DIR does not exist. Skipping Komorebi sync."
    exit 0
fi

echo "Syncing Komorebi config from $WSL_SOURCE_DIR to $WINDOWS_TARGET_DIR"

# Ensure the target parent directory exists
mkdir -p "$(dirname "$WINDOWS_TARGET_DIR")"

# Use rsync to copy files.
# -a: archive mode (preserves permissions, ownership*, times, recursive, etc.)
#     Note: WSL/Windows permission/ownership translation isn't perfect, but -a is generally good.
# --delete: remove files in the destination that are no longer in the source
# Ensure the source directory path ends with a slash / to copy contents
rsync -a --delete "$WSL_SOURCE_DIR/" "$WINDOWS_TARGET_DIR"

echo "Komorebi sync complete."

exit 0
@tpsteiner commented on GitHub (Apr 22, 2025): For me too. Not a big deal. It might be a nice-to-have in the future. I use [chezmoi](https://github.com/twpayne/chezmoi) to manage my dotfiles. It's awesome. On a related note: [XDG compliance](https://specifications.freedesktop.org/basedir-spec/latest/) would also be nice, though doing so will screw up everyone's current config xD Solution to copy on apply for chezmoi, courtesy of Gemini... ``` # ~/.config/chezmoi/chezmoi.toml [data] windows_username = "Tom" # Replace "Tom" with your actual Windows username ``` Paste the following into ~/.local/share/chezmoi/run_after_99-sync-komorebi-to-windows.sh.tmpl ``` #!/bin/bash # vim: set ft=sh: # Exit immediately if a command exits with a non-zero status. set -e # Define the source directory (where chezmoi puts the files in WSL) # Assumes standard chezmoi behavior placing dot_config/komorebi into ~/.config/komorebi WSL_SOURCE_DIR="$HOME/.config/komorebi" # --- Define the target directory on the Windows filesystem --- # Use the windows_username from chezmoi's config data WINDOWS_USER="{{ .windows_username }}" # Construct the WSL path to the Windows target directory WINDOWS_TARGET_DIR="/mnt/c/Users/$WINDOWS_USER/.config/komorebi" # --- End target directory definition --- # Ensure the source directory exists (it should if chezmoi managed files there) if [ ! -d "$WSL_SOURCE_DIR" ]; then echo "Source directory $WSL_SOURCE_DIR does not exist. Skipping Komorebi sync." exit 0 fi echo "Syncing Komorebi config from $WSL_SOURCE_DIR to $WINDOWS_TARGET_DIR" # Ensure the target parent directory exists mkdir -p "$(dirname "$WINDOWS_TARGET_DIR")" # Use rsync to copy files. # -a: archive mode (preserves permissions, ownership*, times, recursive, etc.) # Note: WSL/Windows permission/ownership translation isn't perfect, but -a is generally good. # --delete: remove files in the destination that are no longer in the source # Ensure the source directory path ends with a slash / to copy contents rsync -a --delete "$WSL_SOURCE_DIR/" "$WINDOWS_TARGET_DIR" echo "Komorebi sync complete." exit 0 ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#393
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?