A spurious warning is issued when unstowing a package about stow HOT 43 CLOSED

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

from stow.

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

from stow.

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.

from stow.

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.

from stow.

I finally started working on this again today. It's my top priority for the next release.

from stow.

Thanks folks, your support means a lot :-)

from stow.

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.

from stow.

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.

from stow.

confirmation about the same bug here on arch with stow 2.3.1

from stow.

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.

from stow.

any update?

from stow.

Please see #33 (comment)

I am (painfully) aware of these outstanding issues :-(

from stow.

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

from stow.

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)

from stow.

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

from stow.

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.

from stow.

Yes, but I don't want to maintain a fork :-)

from stow.

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

from stow.

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.

from stow.

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

from stow.

from stow.

You can either ignore the warning (it's harmless) or comment out the two lines of code in Stow.pm which generate it.

from stow.

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

from stow.

Perhaps reverting the commit that causes this issue would be a good stopgap? Along with a bump in the minor/patch version.

from stow.

@aspiers it's been some time. Will you revert said commit and backport it to the latest stable release?

from stow.

I have the same issue as well. No matter what I try to stow I get the same error.

from stow.

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

from stow.

I have the same problem. Any news on this?

from stow.

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.

from stow.

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.

from stow.

@doolio I managed to get past it by removing the symlink, maybe try that?

from stow.

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)

from 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.

from stow.

I am still facing the issue, is there anything I can do in the meantime as a workaround?

from stow.

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.

from stow.

Stow is a nice dotfiles manager, I'm looking forward the problem will be solved :-)

from stow.

For me it shows the errors but also doesn't actually restows. Is this due to this issue ?

from stow.

This bug should have no affect on restowing. At least it doesn't for me. Running the same version as OP.

from stow.

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.

from stow.

Any updates

from stow.

Nice. You can also just comment out the line in Stow.pm which causes that.

from stow.

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)

from stow.

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)"
end

You can put the content to the ~/.config/fish/functions/stow.fish

from stow.