A spurious warning is issued when unstowing a package
ruifm opened this issue · 47 comments
System Information
$ stow --version
stow (GNU Stow) version 2.3.1
$ perl -v
This is perl 5, version 30, subversion 0 (v5.30.0) built for x86_64-linux-thread-multi
$ uname -a
Linux garry 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16 11:29:43 UTC 2019 x86_64 GNU/LinuxDescription
Since this change, everytime I unstow package foo it gives be this message:
$ stow -D --verbose=3 foo
stow dir is /home/user/dotfiles
stow dir path relative to target /home/user is dotfiles
cwd now /home/user
Planning unstow of package foo...
Unstowing from . (cwd=/home/user, stow dir=dotfiles)
Unstowing dotfiles/foo/.foorc
UNLINK: .foorc
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles
and path /home/user/.bar/somerandom_bar_related_dir at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
and path /home/user/.bar/somerandom_different_bar_related_dir at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
Planning unstow of package foo... done
cwd restored to /home/user/dotfiles
cwd now /home/userI will isolate the warning to make it clearer:
$ stow -D foo
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles
and path /home/user/.bar/somerandom_bar_related_dir at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
and path /home/user/.bar/somerandom_different_bar_related_dir at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.I understand this is supposedly added for some unit test edge case but with normal usage is indeed creating a minor annoyance.
Yes, I am seeing this too. Obviously the logic I had in my head when I wrote that was wrong, so I'll have to revisit it.
Perhaps reverting the commit that causes this issue would be a good stopgap? Along with a bump in the minor/patch version.
@aspiers it's been some time. Will you revert said commit and backport it to the latest stable release?
I have the same issue as well. No matter what I try to stow I get the same error.
I can avoid the error by removing the symlink I have in the target directory. Not sure if Stow is working now though as restowing didn't add the missing file...
I have the same problem. Any news on this?
I encountered the same bug when I try to unstowing a package:
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles and path /home/otakutyrant/.steam/steam.pid at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles and path /home/otakutyrant/.steam/sdk32/steam at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
But this bug disappeares after I downgraded stow to 2.2.2-5 in Arch Linux.
confirmation about the same bug here on arch with stow 2.3.1
Downgrading worked for me too. For reference, this is how I did it.
sudo pacman -U https://archive.archlinux.org/packages/s/stow/stow-2.2.2-5-any.pkg.tar.xzSame bug here on Parabola (i686) with stow 2.3.1-3.0. I've not downgraded as others have suggested (I presume I'd have to use the archlinux32 archives?) as I'd prefer not to lose the --dotfiles option introduced in 2.3.0. Any other workaround until this can be fixed?
Thanks for your time and stow.
@doolio I managed to get past it by removing the symlink, maybe try that?
Same bug
stow -v -R -t ~ zsh
UNLINK: .zshrc
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles and path /home/wittyjudge/.steam/sdk32/steam at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles and path /home/wittyjudge/.steam/steam.pid at /usr/share/perl5/vendor_perl/Stow.pm line 966, <DATA> line 22.
LINK: .zshrc => dotfiles/zsh/.zshrc (reverts previous action)
Well, it's been a year since @aspiers mentioned he needed to look at it with really no communication since then, and no changes in 15 months. At this point, I am not sure if this is just abandoned or not. I am either just going to fork it to try and fix it (Perl, so probably not) or just find another solution to using stow.
@bensleveritt thanks. I did see your workaround solution but am apprehensive of just removing the symlink as I don't believe you can simly restow in that case.
@doolio if you run unlink targetfile that was created when running stow, and then re-run the stow command, it will place it back again.
@autoferrit commented on September 16, 2020 4:47 AM:
Well, it's been a year since @aspiers mentioned he needed to look at it with really no communication since then, and no changes in 15 months. At this point, I am not sure if this is just abandoned or not. I am either just going to fork it to try and fix it (Perl, so probably not) or just find another solution to using stow.
Stow is definitely not abandoned - I use it every day, and have every intention of ploughing through the backlog (including this issue which probably annoys me at least as much as everyone else!). If it's any comfort I feel terrible for taking this long so far, and given that my diary is unusually clear from Tuesday, I'm going to risk making a public promise that this will be addressed in a new release by the end of next Sunday - hopefully putting that commitment out there will help me finally stop other things getting in the way this time!
Thanks @aspiers good to see you back! I didn't plan on jumping the stow ship anytime soon even with this minor inconvenience (which is all it really is).
Thank you Adam. I'm sure everyone understands that we all have busy schedules with so many things grappling for our attention and more importantly that Stow like so many other great pieces of free software is maintained by selfless volunteers such as yourself. Stow is one of those pieces of software that is indispensable to me so I personally appreciate all your efforts in maintaining it over the years.
Thanks folks, your support means a lot :-)
@aspiers Yea I am glad it's not abandoned. But given I use stow regularly, it's a pretty annoying error since I can't seem to get rid of it, or hide it easily. And in all honesty, I am glad it is not abandoned and you still want to upkeep it! I think people just wanted to know you had planned on fixing it at some point. And that's good enough for me. I know maintaining OSS is a lot of work.
If I knew perl I would try to help, but I don't really have enough time to help. So I guess in that respect I shouldn't complain too much lol. Anyways, I'm stoked it's on your radar. stow really is to me, the best way to manage dotfiles.
Quick update on this - I've spent most of today getting back into Stow maintenance mode, and I now fully understand this issue (briefly, it's caused by some code which automatically removes dangling symlinks owned by Stow) and I have a fix lined up, although I've taken the opportunity to clean up a bunch of other stuff along the way so it's taken a bit longer than expected. Unfortunately I've run out of time to make a release today (it's almost 2am here), and anyway there's another issue with the Docker images which needs to be addressed before I can make a release, but I'm going to continue with this in the morning. Sorry I didn't quite live up to my foolish promise to cut a new release today, but short of a catastrophe I should have one out this week for sure. I'm hoping it will address some of the other most annoying issues too, but we'll see.
Well folks, not one but two unforeseen circumstances resulted in one of the most unpleasant and distracting weeks I've had in a long while, but everything is resolved now so I'm back to work on Stow.
I'll explain where I am with this particular issue. When unstowing a package, cleanup_invalid_links() is invoked to remove any invalid links owned by Stow. It has been invoking link_owned_by_package() to check whether each existing link is owned by Stow. This in turn calls find_stowed_path() which since 40a0807 was not allowing for the possibility that it could be passed a symlink not owned by Stow with an absolute target. When I introduced 40a0807 this possibility had not occurred to me, which is why we are seeing this erroneous (and benign) warning.
I could just remove the warning but it's not a full fix as it re-raises the question of whether Stow should support symlinks with absolute paths as described in issue #3 (with a proposed solution in PR #68) - which is one of the issues I was hoping to tackle in this current batch of work.
So I'm inclined to spend a little longer getting my head around #3 before deciding the best approach to this. Having said that, in the unlikely case that this warning is causing you serious issues and you need it urgently removed, then please let me know and maybe I can do a quick release just to address that.
I am still facing the issue, is there anything I can do in the meantime as a workaround?
You can either ignore the warning (it's harmless) or comment out the two lines of code in Stow.pm which generate it.
I just started using stow, replacing some custom code that did the same thing, but not as well. I'm using it to link my git dot-file repos (one public and one private) to my home dir. I'm also getting this issue with any existing links that stow does not control. I'll just live with it until a fix shows up in Manjaro.
For any that just want the output to disappear, you can do something like this:
stow OPTIONS 2>&1 | grep -v "BUG in find_stowed_path"
Just note that it redirects all errors to stdout so it might affect other behavior if run inside of a script.
Stow is a nice dotfiles manager, I'm looking forward the problem will be solved :-)
I finally started working on this again today. It's my top priority for the next release.
To add a little colour to that: hoping to get 2.3.2 out the door relatively quickly, and then try to improve the state of --dotfiles for 2.3.3, as that seems to be the other most common cause of problems.
Another quick update:
I could have of course just removed the code causing this warning and closed the issue very quickly without thinking hard about it. But by spending more time and examining the cause of the misunderstanding regarding relative vs. absolute links more deeply, I've found various issues in the code and test suite. And this led me to realise that the join_paths() function which is instrumental in resolving symlinks is fundamentally incapable of dealing with absolute (non-relative) symlinks. So I'm working to fix that, and I think that should help pave the way for proper support for absolute links in the future, potentially helping with issues such as #3, #51, #68 and #76 (to which I have added a new absolute paths label).
any update?
For me it shows the errors but also doesn't actually restows. Is this due to this issue ?
This bug should have no affect on restowing. At least it doesn't for me. Running the same version as OP.
Hey, I appreciate the project and have been using it for years now.
I read this thread and apparently the issue is still yet to be fixed.
Imo this should be considered a feature breaking bug, as without the ability to handle absolute paths the program will simply error out and refuse to do anything. You cannot adopt, override nor remove symlinks with absolute paths as it thinks of those paths as "not owned".
There was a pull request fixing this issue (#68 ) but it has not yet been merged.
Any updates
Please see #33 (comment)
I am (painfully) aware of these outstanding issues :-(
Please see #33 (comment)
I am (painfully) aware of these outstanding issues :-(
Oh I see. Yeah, I can see how that would be stressful. A lot of people depend on or have used your project for managing linux/unix dotfiles and sadly with open source finding people that care enough to help maintaining the project is a challenge.
Probably this being a perl project also has made finding people willing to work on it harder. Please consider asking for help on linux and programming related subs on reddit. Or alternatively consider a rewrite in python or go or another language with a sizable and passionate following that would be more likely to participate as the project is just a little over 2000 lines and this could easily be rebuilt by just a couple developer in a month or less (even though this is risky and might incur having some bugs so probably a last resort).
Either way, please don't feel too pressured by us, stow works and have worked really well for most use cases for the past years, the bugs are minor annoyances but that can for the most part be worked around with small commands and scripts. Take your time :)
Yes it is a real problem these days that it's written in Perl. I think a Python rewrite would be fantastic and I have considered that before as I have a lot of experience in Python. The way to do it would be to figure out how to run the Perl test suite on the Python implementation, get that to 100% pass rate, then rewrite the test suite in Python (or maybe parallelise the two to some degree).
That said, it shouldn't be particularly hard for any Python dev to look at the Stow code and understand most of what's going on straight away. The main challenge is not getting hung up by all the "weird" syntax like @_, $_[0] etc. but that can be learned very quickly.
As a workaround I'm using a little wrapper around stow; HTH someone:
#!/usr/bin/env bash -e -o pipefail
# Forward arguments to GNU stow and strip any spurious warning
# (https://github.com/aspiers/stow/issues/65)
stow "$@" \
2> >(grep -v 'BUG in find_stowed_path? Absolute/relative mismatch' 1>&2)Nice. You can also just comment out the line in Stow.pm which causes that.
Yes, but I don't want to maintain a fork :-)
As a workaround I'm using a little wrapper around
stow; HTH someone:#!/usr/bin/env bash -e -o pipefail # Forward arguments to GNU stow and strip any spurious warning # (https://github.com/aspiers/stow/issues/65) stow "$@" \ 2> >(grep -v 'BUG in find_stowed_path? Absolute/relative mismatch' 1>&2)
Small addition... To make sure this works, you need:
1 - Ensure this script is first in your $PATH
2 - Edit the script to explicitly call /usr/bin/stow
[..snip..]
/usr/bin/stow "$@" \
2> >(grep -v 'BUG in find_stowed_path? Absolute/relative mismatch' 1>&2)Here is the fish shell wrapper function for stow based on @dabrahams
function stow
bash -c "stow $argv 2> >(grep -v 'BUG in find_stowed_path? Absolute/relative mismatch' 1>&2)"
endYou can put the content to the ~/.config/fish/functions/stow.fish
Hello! Just to register that this error is still present in Feb-2024.
I get the following trying to unstow.
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles and path /Users/user/Dropbox/org/roam/contatos.org at /usr/local/Cellar/stow/2.3.1//Library/Perl/5.30/Stow.pm line 966, <DATA> line 22.
BUG in find_stowed_path? Absolute/relative mismatch between Stow dir dotfiles and path /Users/user/Library/Application Support/Google/DriveFS/100920322747728924973/my-drive at /usr/local/Cellar/stow/2.3.1//Library/Perl/5.30/Stow.pm line 966, <DATA> line 22.
IT seems to want to take over Google Drive Backup and Sync's symlinks... Weird.
I hope all is well, and I really (REALLY) hope this project is maintained. I just found out about it and I am having a blast configuring with it!
Thanks!
@fabinhorsff there hasn't been any new releases since 2019 and no new commits on the master branch since 2021, I think it's fair to say that this bug is here to stay for quite a while
aaah man
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.