Filesystem conflict

yupi · 2015-02-25 10:09:05

I got the following upgrading to filesystem-2015.02-1:

error: failed to commit transaction (conflicting files)
filesystem: /home exists in filesystem

Here jakob mentioned
that a similar problem might be due to pacman 4.2 not honoring symlinks anymore. This, of course, would be ridiculous because home is very often symlinked, so perhaps the issue is somewhere else.

clfarron4 · 2015-02-25 10:17:07

Are you reporting a bug or asking for a fix?

The issue regarding pacman 4.2 and symlinks has been covered extensively on the forums, with a bind mount being one of the major suggestions to use instead of symlinks.

WorMzy · 2015-02-25 10:33:13

yupi wrote:

This, of course, would be ridiculous because home is very often symlinked, so perhaps the issue is somewhere else.

Since when? I have never seen /home symlinked, what would be the point?

yupi · 2015-02-25 10:34:03

I was just reporting the upgrade issue which just bit me. I could not find any similar issue in the package upgrade issue branch.

Thank you for the feedback. Could you provide a link to discussion? Or, perhaps, to a bug if there is such?

yupi · 2015-02-25 10:43:12

@WorMzy
Because I want to change its physical location easily. Of course, I can do this with bind mount. But symlinking is easier. Why would pacman honor bind mounts and not honor symlinks? I understand some technical reason, but there's little behavioral difference. With bind mounts I can do the same things as with symlinks.

Scimmia · 2015-02-25 16:01:11

There is no bug report because there is no bug. This is intended behavior.

mcloaked · 2015-02-25 17:51:39

WorMzy wrote:

yupi wrote:
This, of course, would be ridiculous because home is very often symlinked, so perhaps the issue is somewhere else.
Since when? I have never seen /home symlinked, what would be the point?

Sometimes people have separate partitions for / and /opt and /home, but if /opt is not that full then it can be advantageous to have /home as a subdir of /opt within a single partition - so some people make a directory say /opt/Local/home and bind mount that to /home. That way it is still separated from the root partition, and if it fills up will not cause the system to hang or suffer other problems that can happen if the root partition fills up. But at the same time has then combined /home and /opt in a single partition. Of course /home can be the partition mounted via fstab with a subdir such as /home/opt then bind mounted as /opt instead as an alternative way of setting up the basic partitioning. Others have /home and /opt as two separate partitions - but we all have a choice and can do it whichever way feels optimal for each user administering a particular machine. On a laptop I have the root partition on an SSD with /opt as a separate drive within which is a bind mounted /home directory.

Sometimes instead of bind mounting people have used symlinks in this use case, but it seems that pacman no longer is happy with it being done that way. There can be issues if the system uses raid arrays, or encrypted partitions during the boot process when symlinks for these fundamental directories can end up having timing issues for mounting though. So care is needed.

ansak · 2015-03-09 02:28:37

Scimmia wrote:

There is no bug report because there is no bug. This is intended behavior.

I must be a moon-calf, too, despite the 18 year history I have with Linux in at least five distros. I use symlinks for the kinds of reasons mcloaked outlines, and they worked so well for me that I never had to know what a "bind mount" is until now. How much effort would it have cost pacman to honour symlinks as easily as "bind mounts"? What potential problem would honouring symlinks have introduced that we should be thankful that you think our behaviour is at fault, that this behaviour of pacman is desired behaviour, @Scimmia, and not a bug?

If I had been asked (and I shouldn't have been, under the circumstances, I admit it -- I'm the moon-calf here), this would not have been the intended behaviour but a bug. You've just raised an additional hoop I'll have to go through before I can upgrade all the Other things that I actually care about. You're getting this self-deprecating form of the question about it because I expect, in the end, that the hoop isn't very far off the ground. Just not something I should do with my GUI up and running.

But please. Don't just tell me I'm wrong. Tell me why, with my simple system that doesn't include RAID arrays and encrypted partitions (not to mention my simple mind), I should be thankful to be forced to use bind mounts instead of symlinks.

jasonwryan · 2015-03-09 02:35:05

https://lists.archlinux.org/pipermail/p … 16488.html

ansak · 2015-03-09 03:14:13

Thanks a lot Jason...

jasonwryan wrote:

https://lists.archlinux.org/pipermail/p … 16488.html

Okay, I think I understand: Mr Mcrae calls it "poor man's mount points" and says "there are more correct options" but what I see behind it is a kind of laziness (maybe qualifying as one of Larry Wall's virtues) in the service of (potentially) more robust, simpler code. If I don't think too hard it just looks like laziness, without the hint of a virtue at all.

I still call it a highly un-helpful error message. "/home exists in the filesystem" doesn't tell me anything I don't already know and it doesn't look like a cause for any kind of problem. A bit, just a bit more verbosity would help us "set and forget" people. Just a message like "pacman no longer supports symlinks; please use bind mounts instead". Otherwise it looks something like, "Error! 2 plus 2 still equals 4!"

We don't all follow these discussions down to the nth detail and this kind of change rather blind-sides us. Be kind to us poor mortals, please.

Last edited by ansak (2015-03-09 03:14:31)

jasonwryan · 2015-03-09 03:19:29

You can always look at the changelog: https://projects.archlinux.org/pacman.git/tree/NEWS

As for the "set and forget" thing; Arch does its best to overcome that lethargy for you. That's why you love it, right?

ansak · 2015-03-09 15:34:56

jasonwryan wrote:

As for the "set and forget" thing; Arch does its best to overcome that lethargy for you. That's why you love it, right?

fail: You forgot the with that line. "set and forget" was always a basic given. The fact that Arch is not honouring it is one of my growing irritations. It's not a form of lethargy. It's that I set this computer up and I want to (a) keep my patches up to date to be secure and (b) not mess with what's working just fine for me -- for that reason, I'm still dubious about the whole bin-unification thing although I can understand how that makes package maintainers' lives easier.

When something as basic as pacman walks away from supporting symlink navigation, it shouldn't require ME to keep up to date with a news feed. It should require pacman's package maintainer to give due and several-release-ahead warning that it's going away with links to what to do before the deadline arrives.

What does that look like? For at least three months before the boom is lowered, pacman continues to allow symlinks but verbiates noisily to the screen when it encounters them, warning the user that by such and such a date symlink support is going away. Ending such messages with "Please switch all your symlinks to bind mounts as soon as possible." would be maximally helpful.

I'm not against upgrading. I am against upgrading that looks like a downgrade for even brief periods of time, as this did (it's improved now to a "wash", almost). And replying to this kind of concern with "that's not an error; it's desired behaviour" is pompous. Calling a common-case configuration choice "Poor man's mount points" is unnecessarily pejorative. It may be cooler, smoother and "better" to shun symlinks, if only in some way that's hard to explain except to full-patch insiders, but there's no need to alienate everyone else.

And as for "love", I'm "loving" it less every month. The rest of my life is too full or I'd have abandoned arch by now for reasons best explained by the creator of musl-libc on ewontfix.com, especially in post 14. Even the guy who got me onto arch (and it seemed like a pretty sweet place to me at the time) has left the building.

anyways, thanks for the attempt at cheeriness. I appreciated that at least.

Scimmia · 2015-03-09 15:42:39

ansak wrote:

And replying to this kind of concern with "that's not an error; it's desired behaviour" is pompous.

You're seeing what you want to see. Someone asked if there was a bug report, I responded that it's intended behavior, which by definition is not a bug.

Trilby · 2015-03-09 15:51:58

Ansak, I fully agree on the strategy you lay out that would be maximally helpful. In a perfect world, that would have been the approach. Perhaps a news item would have been helpful. But much of the rest of your post is not quite as agreeable. Assuming it is anyone's responsibility to go out of their way to inform you of things is just bass ackwards. And to claim you do not have a responsibility to keep up to date on news and changes is just silly. It's your computer - you are responsible for it. You ran the updates, you installed the new versions of software. Do not complain that something free is not up to your standards. This is where there is a huge difference between a feature request and a complaint. By all means make suggestions on how the development process could be better - but drop the blame: no one else is responsible for your system.

ansak · 2015-03-09 16:16:33

Trilby wrote:

... but drop the blame: no one else is responsible for your system ...

apparently I'm not the only one open to the charge of seeing what I want to see... calling myself a moon calf first off was an attempt to colour everything else I was saying in a neighbourly light. I tried to pale the rest of it down by saying "it looks like" not "it is a" downgrade, etc. I'm not expecting anyone to take responsibility for my system. I was only hoping for them to take responsibility for the potential pitfalls their design choices were making for others: basic neighbourliness, I called it.

epic fail on my part i guess. good night and good luck.

Arch Linux

#1 2015-02-25 10:09:05

Filesystem conflict

#2 2015-02-25 10:17:07

Re: Filesystem conflict

#3 2015-02-25 10:33:13

Re: Filesystem conflict

#4 2015-02-25 10:34:03

Re: Filesystem conflict

#5 2015-02-25 10:43:12

Re: Filesystem conflict

#6 2015-02-25 16:01:11

Re: Filesystem conflict

#7 2015-02-25 17:51:39

Re: Filesystem conflict

#8 2015-03-09 02:28:37

Re: Filesystem conflict

#9 2015-03-09 02:35:05

Re: Filesystem conflict

#10 2015-03-09 03:14:13

Re: Filesystem conflict

#11 2015-03-09 03:19:29

Re: Filesystem conflict

#12 2015-03-09 15:34:56

Re: Filesystem conflict

#13 2015-03-09 15:42:39

Re: Filesystem conflict

#14 2015-03-09 15:51:58

Re: Filesystem conflict

#15 2015-03-09 16:16:33

Re: Filesystem conflict

Board footer