Dotfiles option doesn't work with directories #33

lhindir · 2019-04-09T00:30:49Z

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.

The text was updated successfully, but these errors were encountered:

aspiers · 2019-06-28T15:51:04Z

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

bricewge · 2019-06-29T12:55:27Z

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 · 2019-06-29T13:14:05Z

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 · 2019-06-30T17:55:02Z

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 · 2019-07-10T12:30:00Z

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 · 2019-08-24T20:20:40Z

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 · 2019-09-06T00:55:49Z

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

Unfortunately the dotfiles options is currently broken for directories, see aspiers/stow#33.

NPastorale · 2020-01-28T10:27:49Z

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 · 2020-03-29T04:26:21Z

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!

`stow` supports the `--dotfiles` option which causes files beginning with the prefix `dot-` in the stow directory to be symlinked with a literal period character instead. This avoids the need to have hidden files in the stow directory. Unfortunately, this option is not fully working for hidden directories (see aspiers/stow#33). Hence, packages containing hidden directories remain unchanged for now. Add a README file to help with remembering how the installation works for each package.

The recent addition of the `--dotfiles` option allows me to name the files in a way so that they are not hidden by the shell. However, as noted in the README, Stow does not yet support using this option with subdirectories (see <aspiers/stow#33>), so these have not been converted to use the `dot-*` names.

AitorATuin · 2020-05-24T16:21:58Z

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 · 2020-06-13T02:02:04Z

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 · 2020-07-15T13:06:56Z

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

qbedard · 2020-07-15T15:54:35Z

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

queensferryme · 2020-07-29T11:18:34Z

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 · 2020-08-10T19:22:23Z

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

See aspiers/stow#33 Until it's resolved dirs can't use dot- prefix

jamieeeeeeeee · 2021-01-02T19:33:32Z

Just hit this too. Any timeline for a fix?

han1475 · 2021-01-21T05:21:00Z

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 · 2021-03-29T12:25:21Z

It would be nice to have this fixed!

SfyMantissa · 2023-07-10T22:00:39Z

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.

ErebusBat · 2023-07-11T15:15:11Z

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.

This is blocked by aspiers/stow#33 I get the following error: stow: ERROR: stow_contents() called with non-directory path: .dotfiles/all/.config

Thanks to aspiers/stow#33 (comment)

The recent addition of the `--dotfiles` option allows me to name the files in a way so that they are not hidden by the shell. However, as noted in the README, Stow does not yet support using this option with subdirectories (see <aspiers/stow#33>), so these have not been converted to use the `dot-*` names.

phunni · 2023-11-09T20:41:00Z

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 · 2023-11-10T00:32:24Z

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 · 2023-11-10T08:47:02Z

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

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

phunni · 2023-11-26T11:12:32Z

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.

See aspiers/stow#33

diego898 · 2024-01-20T22:07:25Z

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

HaleTom · 2024-01-21T09:13:19Z

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

HaleTom · 2024-01-21T09:58:49Z

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

niklaas · 2024-01-22T09:54:31Z

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 · 2024-01-22T15:59:45Z

Thanks @niklaas for raising this on the mailing list.

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

xentatt · 2024-02-23T11:25:18Z

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

turn out dot-config -> .config not actually working gh issues has been open for a while aspiers/stow#33

aspiers · 2024-04-05T13:00:42Z

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.

Brottweiler · 2024-04-05T13:08:34Z

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

lgrosz · 2024-04-06T03:45:22Z

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

aspiers · 2024-04-06T14:39:48Z

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.

aspiers · 2024-04-07T14:15:51Z

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.

Stow walks the package and target tree hierarchies by using mutually recursive pairs of functions: - `stow_contents()` and `stow_node()` - `unstow_contents()` and `unstow_node()` As Stow runs its planning from the target directory (`plan_*()` both call `within_target_do()`), previously the parameters for these included: - `$target_subpath` (or `$target_subdir` in the `*_node()` functions): the relative path from the target top-level directory to the target subdirectory (initially `.` at the beginning of recursion). For example, this could be `dir1/subdir1/file1`. - `$source`: the relative path from the target _subdirectory_ (N.B. _not_ top-level directory) to the package subdirectory. For example, if the relative path to the Stow directory is `../stow`, this could be `../../../stow/pkg1/dir1/subdir1/file1`. This is used when stowing to construct a new link, or when unstowing to detect whether the link can be unstowed. Each time it descends into a further subdirectory of the target and package, it appends the new path segment onto both of these, and also prefixes `$source` with another `..`. When the `--dotfiles` parameter is enabled, it adjusts `$target_subdir`, performing the `dot-foo` => `.foo` adjustment on all segments of the path in one go. In this case, `$target_subpath` could be something like `.dir1/subdir1/file1`, and the corresponding `$source` could be something like `../../../stow/pkg1/dot-dir1/subdir1/file1`. However this doesn't leave an easy way to obtain the relative path from the target _top-level_ directory to the package subdirectory (i.e. `../stow/pkg1/dot-dir1/subdir1/file1`), which is needed for checking its existence and if necessary iterating over its contents. The current implementation solves this by including an extra `$level` parameter which tracks the recursion depth, and uses that to strip the right number of leading path segments off the front of `$source`. (In the above example, it would remove `../..`.) This implementation isn't the most elegant because: - It involves adding things to `$source` and then removing them again. - It performs the `dot-` => `.` adjustment on every path segment at each level, which is overkill, since when recursing down a level, only adjustment on the final subdirectory is required since the higher segments have already had any required adjustment. This in turn requires `adjust_dotfile` to be more complex than it needs to be. It also prevents a potential future where we might want Stow to optionally start iterating from within a subdirectory of the whole package install image / target tree, avoiding adjustment at higher levels and only doing it at the levels below the starting point. - It requires passing an extra `$level` parameter which can be automatically calculated simply by counting the number of slashes in `$target_subpath`. So change the `$source` recursion parameter to instead track the relative path from the top-level package directory to the package subdirectory or file being considered for (un)stowing, and rename it to avoid the ambiguity caused by the word "source". Also automatically calculate the depth simply by counting the number of slashes, and reconstruct `$source` when needed by combining the relative path to the Stow directory with the package name and `$target_subpath`. Closes #33.

aspiers · 2024-04-07T21:53:04Z

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.

Issue: aspiers/stow#33

aspiers added bug help wanted labels Jun 28, 2019

pvsr mentioned this issue Aug 6, 2019

Keep track of adjusted and original dotfile paths #63

Closed

DrPyser mentioned this issue Dec 30, 2019

stow --dotfiles option broken DrPyser/configs#2

Open

pSub added a commit to pSub/configs that referenced this issue Jan 7, 2020

[stow] use dotfiles options for discoverability

4beb800

Unfortunately the dotfiles options is currently broken for directories, see aspiers/stow#33.

EliaGeretto mentioned this issue Jul 6, 2020

dotfiles option not working with .config folder #73

Closed

frelind added a commit to frelind/dotfiles that referenced this issue Aug 10, 2020

Rename dot-vim folder due to bug in stow

9f5d96d

See aspiers/stow#33 Until it's resolved dirs can't use dot- prefix

alexpearce mentioned this issue Feb 18, 2021

Managing dotfiles with GNU stow alexpearce/home#27

Closed

aspiers added this to the Release 2.3.3 milestone Apr 4, 2021

aspiers added the dotfiles Issues with --dotfiles option label Apr 4, 2021

sinarf added a commit to sinarf/dotfiles that referenced this issue Aug 4, 2023

Use the --dotfiles option in stow

33a3bff

This is blocked by aspiers/stow#33 I get the following error: stow: ERROR: stow_contents() called with non-directory path: .dotfiles/all/.config

sinarf added a commit to sinarf/dotfiles that referenced this issue Aug 4, 2023

[workaround] use --dotfiles with directory

b34f5e6

Thanks to aspiers/stow#33 (comment)

flokoe added a commit to flokoe/dotfiles-devcontainer that referenced this issue Jan 17, 2024

Add functionality to remove existing default configs

e5b817b

See aspiers/stow#33

Kapocsi added a commit to Kapocsi/dotfiles that referenced this issue Mar 17, 2024

add neovim config

91dba8b

turn out dot-config -> .config not actually working gh issues has been open for a while aspiers/stow#33

aspiers modified the milestones: Release 2.4.1, Release 2.4.0 Apr 6, 2024

aspiers mentioned this issue Apr 7, 2024

improve recursion and fix various issues with unstowing / --dotfiles #107

Merged

aspiers closed this as completed in #107 Apr 7, 2024

aspiers self-assigned this Apr 7, 2024

kittydoor added a commit to kittydoor/dotfiles that referenced this issue Jun 17, 2024

Renamed all dot- files to . until GNU stow issue is resolved

8b60d8b

Issue: aspiers/stow#33

Dotfiles option doesn't work with directories #33

Dotfiles option doesn't work with directories #33

Comments

lhindir commented Apr 9, 2019

aspiers commented Jun 28, 2019

bricewge commented Jun 29, 2019 • edited Loading

aspiers commented Jun 29, 2019

jvkersch commented Jun 30, 2019

jvkersch commented Jul 10, 2019

mattmc3 commented Aug 24, 2019

gutierri commented Sep 6, 2019

NPastorale commented Jan 28, 2020 • edited Loading

rdrr commented Mar 29, 2020 • edited Loading

AitorATuin commented May 24, 2020 • edited Loading

ghost commented Jun 13, 2020

samuelhnrq commented Jul 15, 2020

qbedard commented Jul 15, 2020

queensferryme commented Jul 29, 2020

frelind commented Aug 10, 2020

jamieeeeeeeee commented Jan 2, 2021 • edited Loading

han1475 commented Jan 21, 2021

KucharczykL commented Mar 29, 2021

SfyMantissa commented Jul 10, 2023

ErebusBat commented Jul 11, 2023

phunni commented Nov 9, 2023

luisduque-ve commented Nov 10, 2023

doolio commented Nov 10, 2023

phunni commented Nov 26, 2023

diego898 commented Jan 20, 2024

HaleTom commented Jan 21, 2024 • edited Loading

HaleTom commented Jan 21, 2024

niklaas commented Jan 22, 2024

HaleTom commented Jan 22, 2024 • edited Loading

xentatt commented Feb 23, 2024

aspiers commented Apr 5, 2024

Brottweiler commented Apr 5, 2024 • edited Loading

lgrosz commented Apr 6, 2024

aspiers commented Apr 6, 2024

aspiers commented Apr 7, 2024

aspiers commented Apr 7, 2024

bricewge commented Jun 29, 2019 •

edited

Loading

NPastorale commented Jan 28, 2020 •

edited

Loading

rdrr commented Mar 29, 2020 •

edited

Loading

AitorATuin commented May 24, 2020 •

edited

Loading

jamieeeeeeeee commented Jan 2, 2021 •

edited

Loading

HaleTom commented Jan 21, 2024 •

edited

Loading

HaleTom commented Jan 22, 2024 •

edited

Loading

Brottweiler commented Apr 5, 2024 •

edited

Loading