Dotfiles option doesn't work with directories

lhindir opened this issue 6 years ago · 53 comments

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 commented 5 years ago

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

bricewge commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.

👍2

jvkersch commented 5 years ago

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.

👍3

mattmc3 commented 5 years ago

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

👍2

gutierri commented 5 years ago

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

👍3

NPastorale commented 5 years ago

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!!

👍16

rdrr commented 5 years ago

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 commented 4 years ago

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.

🎉7

Deleted user commented 4 years ago

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

👍1
👎1

samuelhnrq commented 4 years ago

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

👍18
😕3

qbedard commented 4 years ago

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

queensferryme commented 4 years ago

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?

👍25

frelind commented 4 years ago

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

👍14

jamieeeeeeeee commented 4 years ago

Just hit this too. Any timeline for a fix?

👍10

han1475 commented 4 years ago

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

👍2

KucharczykL commented 4 years ago

It would be nice to have this fixed!

👍10

hurricanehrndz commented 3 years ago

This works for now

~/dotfiles on  stow [?]
❯ /usr/local/bin/tree  -l tmux
tmux
└── dot-config -> .config
    └── tmux
        └── tmux.conf

2 directories, 1 file

~/dotfiles on  stow [?]
❯ stow --ignore="^dot-config" tmux

genevera commented 3 years ago

Can this get fixed? It's like 2 years old :(

👍14

hurricanehrndz commented 3 years ago

Use chezmoi it does support this out of the box.

…

Sent from my iPhone

On Nov 10, 2021, at 10:32 AM, genevera ***@***.***> wrote: Can this get fixed? It's like 2 years old :( — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

👎8
❤️1

raveensrk commented 3 years ago

Can we fix this yet? 🙏 Just got hit by this bug today?

--dotfiles option for packages with dot-directories/dot-files does not work
usual packages with .directories/.files work

👍2

jonathannerat commented 3 years ago

I got tired of waiting for this to be merged. *

@AitorATuin would you be ok with me creating an AUR package using your patches? I would eventually remove it if your PR gets merged but until then I would love to have an easy way to install this.

EDIT: the package is now in the AUR as stow-dotfiles-git

*EDIT2: want to apologize about the wording here in case aspiers ever reads it while going through their backlog. I just assumed that he only was in charge of maintaining a mirror, didn't think he was working on it. Hopefully this gets merged and we can stop relying on manually patched versions of stow!

👍7

AitorATuin commented 3 years ago

@jonathannerat Sure, use it if you want.

bbkane commented 3 years ago

This issue (and my difficulties trying to figure out what actions stow will take), prompted me to write my own alternative I'm calling fling. It's working well for my personal use; maybe ya'll would like it too :)

👍1
😕1

jsf9k commented 3 years ago

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

This works for me too, although in my particular case is isn't a feasible solution. I had to rename a dot-foo directory to .foo instead.

👍1
👀1

sudhirkhanger commented 3 years ago

Since a lot of configs are going to be inside ~/.config which will have to exist before stowing the above solution doesn't work.

esslamben commented 3 years ago

Not sure if this is much help but I was able to get round the .config issue by nesting my .config folder in a config folder. I then run stow config and it places my nvim folder inside of .config in my home dir. The .config folder itself isn't sym linked but the folders in my dotfiles are.

billyogat commented 2 years ago

I ran into this issue too.

stow directory was setup as

.
└── nvim
    └── dot-config
        └── nvim

I needed to update to following to get my setup to work.

.
└── nvim
    └── .config
        └── nvim

CrBoy commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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.

❤️21
🚀2

doolio commented 2 years ago

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

👍9

aspiers commented 2 years ago

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! 😆

❤️7

SfyMantissa commented a year ago

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

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

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.

👍1

ErebusBat commented a year ago

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.

👍3

phunni commented a year ago

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 commented a year ago

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 commented a year ago

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

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

phunni commented a year ago

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 commented 10 months ago

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

HaleTom commented 10 months ago

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

HaleTom commented 10 months ago

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

👍2
👎2
❤️1

niklaas commented 10 months ago

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. :)

👍2

HaleTom commented 10 months ago

Thanks @niklaas for raising this on the mailing list.

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

👍2

xentatt commented 9 months ago

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

aspiers commented 7 months ago

For now, please see the interim update and apology here: #70 (comment)

TL;DR: this bug is fixed in the dev branch, and I will do my utmost to cut a release this weekend.

Proper communications to follow this weekend.

🎉6
❤️18
🚀1

Brottweiler commented 7 months ago

@aspiers cheers mate, stow has always been perfect for me and while there could be bugs fixed or features added it does what it says on the tin and you never abandoned it. I'm thankful for that!

👍2
❤️3

lgrosz commented 7 months ago

Very excited to see progress on this issue. Hopefully this weekend I can finally remove the hidden directories in my dotfiles repository!

❤️1

aspiers commented 7 months ago

I have now merged dev into master so technically this is fixed; however I have an improved fix nearly done which I'm hoping to be able to squeeze into the next release, so leaving this open for now.

🎉5
❤️7

aspiers commented 7 months ago

It was a nightmare to iron out all the details but I finally have the improved fix working locally, and I'm now documenting it.

🎉14

aspiers commented 7 months ago

v2.4.0 is released with this fix! See https://ftp.gnu.org/gnu/stow/

I'm just updating the website and preparing an announcement email.

🎉23
❤️12
🚀4