stow
stow copied to clipboard
aspiers
A spurious warning is issued when unstowing a package
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/Linux
Description
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/user
I 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 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.
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.xz
Same 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.
@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.
Well, it's a meaningless error that can be easily ignored. Don't get me wrong, I'm still glad it's not abandoned, but this issue isn't that big a deal.
On Tue, Oct 27, 2020, 3:29 PM Shawn McElroy [email protected] wrote:
@aspiers https://github.com/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.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/aspiers/stow/issues/65#issuecomment-717484436, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFUK6O4IEPR5DEBL7ANY33TSM4NTNANCNFSM4INEGQCQ .
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 40a080718505 was not allowing for the possibility that it could be passed a symlink not owned by Stow with an absolute target. When I introduced 40a080718505 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).
