Dotfiles option doesn't work with directories

[lhindir]

Paging @jvkersch in case he has any insight.

I use stow to manage my dotfiles. If I am trying to stow my config for zathura, I run stow --dotfiles zathura from ~/dotfiles, which contains zathura/dot-config/zathura/zathurarc. This outputs:

stow: ERROR: stow_contents() called with non-directory path: dotfiles/zathura/.config

I have no problem if I change the path to zathura/.config. Furthermore, stow --dotfiles bash works fine on the file bash/dot-bashrc. It only fails with directories.

I'll freely admit I know little of the internals here, so I'm sorry if I'm just misunderstanding how to use it. But the error message makes it seem like stow is converting the path before getting the path contents and stowing, when it should be getting the path contents, then converting the path, and finally stowing.

Thanks for any insight you can provide.

[aspiers]

Thanks for the report! I didn't implement --dotfiles, so would welcome some help triaging this one.

[bricewge]

I got bitten by this one too when trying the new release 2.3.0, following is more verbose log when the issue is triggered. Hopefully my comment isn't just seen as a noisy +1 and can help in debugging...

$ stow --ignore='^setup.sh' --ignore='^README.*' --ignore='^@.*'--ignore='^_.*' --target="$HOME" --no-folding --dotfiles alacritty --verbose=5
stow dir is /home/bricewge/project/dotfiles
stow dir path relative to target /home/bricewge is project/dotfiles
cwd now /home/bricewge
cwd restored to /home/bricewge/project/dotfiles
cwd now /home/bricewge
Planning stow of package alacritty...
. not protected
Stowing contents of project/dotfiles/alacritty (cwd=/home/bricewge)
  => project/dotfiles/alacritty
  is_a_node(.)
  link_task_action(.): no task
  dir_task_action(.): no task
    parent_link_scheduled_for_removal(.): prefix
    parent_link_scheduled_for_removal(.): returning false
  is_a_node(.): really exists
  Ignoring path _alacritty.terminfo due to --ignore=(?^:^_.*\z)
  Ignoring path setup.sh due to --ignore=(?^:^setup.sh\z)
  project/dotfiles/alacritty/.stow-local-ignore didn't exist
  /home/bricewge/.stow-global-ignore didn't exist
  Using built-in ignore list
    Ignore list regexp for paths:    /(?^:(^|/)(^/COPYING|^/LICENSE.*|^/README.*|^/\.stow\-local\-ignore$)(/|$))/
    Ignore list regexp for segments: /(?^:^(\.git|.+~|\.#.+|\.svn|CVS|#.*#|\.gitignore|_darcs|\.hg|\.cvsignore|.+,v|RCS)$)/
  Not ignoring dot-config
  Adjusting: dot-config => .config
Stowing project/dotfiles / alacritty / .config
  => project/dotfiles/alacritty/dot-config
  is_a_link(.config)
  link_task_action(.config): no task
  is_a_link(.config): returning 0
  is_a_node(.config)
  link_task_action(.config): no task
  dir_task_action(.config): no task
    parent_link_scheduled_for_removal(.config): prefix .config
    parent_link_scheduled_for_removal(.config): returning false
  is_a_node(.config): really exists
  Evaluate existing node: .config
  is_a_dir(.config)
  dir_task_action(.config): no task
    parent_link_scheduled_for_removal(.config): prefix .config
    parent_link_scheduled_for_removal(.config): returning false
  is_a_dir(.config): real dir
.config not protected
Stowing contents of project/dotfiles/alacritty/.config (cwd=/home/bricewge)
  => ../project/dotfiles/alacritty/dot-config
stow: ERROR: stow_contents() called with non-directory path: project/dotfiles/alacritty/.config

[aspiers]

Definitely not noise, thanks a lot @bricewge for the extra debug! Unfortunately I'm now packing for a 2 week holiday so am unlikely to have time to look at this soon, but if anyone else can make headway in my absence that would be awesome :)

[jvkersch]

Apologies for not replying to the earlier report. I will try to reproduce and I'll see if I can make any headway before @aspiers returns from vacation.

[jvkersch]

I was able to reproduce, thanks all for the detailed info. I think we expand the stow directory too early on; my assumption when originally implementing this was that the dot- entries would be at the top-level in the stow directory, but this is not the case here. Will do some more digging.

[mattmc3]

In the mean time, I've been using --target and a separate stow directory for ~/.config as a work around:

stow -v --dotfiles --target=$HOME/.config stow-config

[gutierri]

I have this same structure, one way that works is to keep ~/dotfiles at the root of $ HOME and this command works (@lhindir):

$ (~/dotfiles) stow -R --dotfiles zathura/ -v
LINK: .config => laptop/zathura/dot-config

And yes, indeed there is a bug, because in my environment if I try to pass a target it returns this same message:

$ (~/dotfiles) stow -R --dotfiles -t ~ zathura/ -v
stow: ERROR: unstow_contents() called with non-directory path: Workspace/git.gutierri.me/laptop/zathura/.config

[NPastorale]

I just came across this bug. and read through this issue and #63. It's not a dealbreaker (at least not for my use case), but it would be nice to have this feature working. Is there any ETA for this fix?
Thanks!!

[rdrr]

Also, stow -D --dotfiles does not seem to work at all, even when files do not contain any "dot-filename" replacements.

We get the to:
Planning unstow of package *...done
but there is no
UNLINK: *
when normally unstowing a package.

To echo NPastorale, this would be a great feature. Thanks!

[AitorATuin]

This attempts to fix this problem: #70

I did not test it properly (a very basic use case with a directory) yet. I will test it with a deeper layer of directories.

I have added some unit tests and the pull requests is building in the CI system. I'm using it locally now also and seems to work.

[ghost]

It would have been lovely to have the limitations of the --dotfiles option in the manual published/released while waiting for the fix to be pushed out

[samuelhnrq]

It's been more than a year the bug was reported and two months since a fix has been proposed, any updates on this?

[timbedard]

Indeed. Would love to see the fix get merged. 🙏

[queensferryme]

Came across the same issue today. Would highly appreciate if the fix got merged.

Also I can help noticing that it has been almost a whole year since the last commit on the master branch. Does the dev team need any help maintaining this project?

[frelind]

Just stumbled on this bug, would be nice if the fix got released.

[jamieeeeeeeee]

Just hit this too. Any timeline for a fix?

[han1475]

I got bitten by this one too when use stow to manage my dotfiles(e.g. ~/dotfiles/emacs/dot-emacs.d => ~/.emacs.d).

I found that ensuring the ~/.emacs.d directory doesn't exist(e.g. rm -rf ~/.emacs.d) before running stow --dotfiles emacs can solve this problem.

I don't know why, but it works for me. I use the latest release 2.3.1

[KucharczykL]

It would be nice to have this fixed!

[CrBoy]

Thanks to @hurricanehrndz, I just made a workaround for this problem. My workaround includes a .stow-local-ignore instead of using --ignore manually.

(I have a .stowrc with --target=$HOME --dotfiles --verbose)

[~/_dotfiles/stowable]
$ tree -a fish
fish
├── .config -> dot-config
├── .stow-local-ignore
└── dot-config
    └── fish
        ├── config.fish
        ├── ...
        ├── ...
        └── ...........

7 directories, 4 files

[~/_dotfiles/stowable]
$ cat fish/.stow-local-ignore
dot-config

[~/_dotfiles/stowable]
$ stow fish   
LINK: .config/fish => ../_dotfiles/stowable/fish/.config/fish

[victorz]

@aspiers hasn't been seen in this thread as far as I can see since 2019. Has he given up on this project or has anyone seen him active in this repo since? I see he's active on GitHub very recently though, so surely -- and hopefully -- he's just busy (for almost 4 years)? Anyone know?

[raveensrk]

He is probably busy. I think this project needs a new maintainer.

…

On Wed, 15 Feb 2023 at 17:20, Victor Zamanian ***@***.***> wrote: @aspiers <https://github.com/aspiers> hasn't been seen in this thread as far as I can see since 2019. Has he given up on this project or has anyone seen him active in this repo since? I see he's active on GitHub very recently though, so surely -- and hopefully -- he's just busy (for almost 4 years)? Anyone know? — Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJV6L7BVUNGMAYCXFE72DSTWXS7HLANCNFSM4HENOCFQ> . You are receiving this because you commented.Message ID: ***@***.***>

[aspiers]

Yes I'm extremely busy with work but definitely haven't given up on Stow - I use it every day, and still deeply care about it despite appearances. I also see all the issues and PRs and requests for help, file them into an ever-growing TODO list, and live with the constant guilt of not being a good maintainer.

I think you're right - I need to find a co-maintainer.

FWIW, I expect to complete two major work projects within a matter of weeks, at which point I intend to take a holiday - and one of the things I would love to do is catch up on this Stow backlog. But I'm aware I've been saying things like that for a few years now, and have so far failed to follow through, so finding a co-maintainer would protect against the current bus factor of 1.

[doolio]

Adam please don't spend your holidays working on stow. We all need proper rest and recuperation.

[aspiers]

That's very kind of you to say @doolio - and of course you are right about the importance of rest ... but actually I would find working on Stow quite a nice and enjoyable way of relaxing, and it would remove a lot of the stress I feel from having neglected it for so long! 😆

[SfyMantissa]

Bump.
Encountered the same issue and Google magic led me here.

1. This workflow fails.

sfy@neonblaze: ~/repos/dotfiles ❱❱ tree -d local
local
└── dot-local
    └── share
        └── applications

4 directories
sfy@neonblaze: ~/repos/dotfiles ❱❱ stow --dotfiles --verbose --target=$HOME --restow local
stow: ERROR: unstow_contents() called with non-directory path: repos/dotfiles/local/.local

2. Had to change dot- back to . — workflow below works fine.

sfy@neonblaze: ~/repos/dotfiles ❱❱ tree -ad local
local
└── .local
    └── share
        └── applications

4 directories
sfy@neonblaze: ~/repos/dotfiles ❱❱ stow --verbose --target=$HOME --restow local
LINK: .local/share/applications => ../../repos/dotfiles/local/.local/share/applications

Looking forward to tweaks for the --dotfiles flag, because it would be really handy.

[ErebusBat]

FWIW I ended up switching to twpayne/chezmoi specifically because of this issue.

It was a PIA; however it (Chezmoi) does handle things much better, especially secrets.

[phunni]

Surprised to see (what seems to me) such a major issue still unresolved. I've just started playing with stow in order to manage files in my home directory and it looks like I'll either have to rename dot-* to .* or switch to a different solution. Both of which would be fairly annoying...

[luisduque-ve]

Surprised to see (what seems to me) such a major issue still unresolved. I've just started playing with stow in order to manage files in my home directory and it looks like I'll either have to rename dot-* to .* or switch to a different solution. Both of which would be fairly annoying...

I don't understand why this project isn't archived already tbh, I was in love with stow so much but the lack of maintenance force me to look another alternatives, I tried chezmoi and is completely awesome, you probably want to take a look to it.

[doolio]

it looks like I'll either have to rename dot-* to .*

The --dotfiles option works for files just not directories at the moment.

[phunni]

it looks like I'll either have to rename dot-* to .*

The --dotfiles option works for files just not directories at the moment.

It's directories that are the problem in my case. Mostly anyway.

[diego898]

A real shame this still doesn’t work - any pull requests/forks that work for anyone?

[HaleTom]

@diego898 take a look at #63 for a quick-start on a PR to fix this.

[HaleTom]

This project seems largely unmaintained. Consider instead: https://www.chezmoi.io/

[niklaas]

This project seems largely unmaintained.

Hm, I'm wondering whether this is the wrong channel to raise attention about this issue. I just sent an email to the bug-stow mailing list to make sure.

Consider instead: https://www.chezmoi.io/

Thanks for the suggestion. According to https://www.chezmoi.io/comparison-table/, chezmoi uses files instead of symlinks which might be to much of an incompatibility for users of stow. Just mentioning to make people aware. :)

[HaleTom]

Thanks @niklaas for raising this on the mailing list.

chezmoi does have a symlinks mode, but note the limitations.

[xentatt]

Still having this bug :(
just for anyone who wants to stick with stow can try this implementation of it in C++ https://github.com/majorkingleo/xstow