FS#8156 - pacman does not detect conflict between symlink and files/directories

Attached to Project: Pacman
Opened by Pierre Schmitz (Pierre) - Friday, 28 September 2007, 18:25 GMT
Last edited by Dan McGee (toofishes) - Sunday, 06 January 2008, 17:34 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Medium
Priority Normal
Reported Version 3.0.6
Due in Version 3.1.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Summary and Info:
If there is a directory which belongs to an allready installed package and the user installs a new package including a symlink named after that directory, pacman does not detect this conflict and just ignores the symlink. This should not happen; especially when the directory and the target of the symlink are different.

Steps to Reproduce:
This problem is the reason of this Bug: http://bugs.archlinux.org/task/8141

Here are two PKGBUILD to reproduce the problem. Pacman does not complain about anything when installing test1 after test2. But the symlink in test2 is lost and software which relies on this will stop working.

arch=('i686' 'x86_64')

build() {
install -d $startdir/pkg/test/
touch $startdir/pkg/test/file

arch=('i686' 'x86_64')

build() {
install -d $startdir/pkg/test2/
touch $startdir/pkg/test2/file2
ln -s $startdir/pkg/test2 $startdir/pkg/test
This task depends upon

This task blocks these from closing
 FS#8109 - Pacman 3.1 Release Roadmap 
Closed by  Dan McGee (toofishes)
Sunday, 06 January 2008, 17:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in GIT.
Comment by Dan McGee (toofishes) - Friday, 28 September 2007, 18:56 GMT
Anyone test this with pacman GIT? I really overhauled the way pacman looks for file/symlink/directory conflicts, so it could be completely different behavior than pacman 3.0.X.
Comment by Xavier (shining) - Friday, 28 September 2007, 22:14 GMT
Isn't this  bug 7484  ?
I can't reproduce this with either 3.0.6 or 3.1. Maybe I'm doing something wrong..

But while it works with 3.1, I didn't get the expected behavior.
I thought it was supposed to trigger case 9 : /* case 9: existing symlink, dir in package */
But the --debug output shows this message : extract: skipping dir extraction of %s\n
which is the case 12. So I'm pretty confused..
Comment by Xavier (shining) - Sunday, 04 November 2007, 23:26 GMT
I should have looked at  bug 8141 , which helped me understand the problem.
You needed a /usr/lib/php/extensions -> /usr/lib/php/20060613/ symlink.
The problem is that there already was a /usr/lib/php/extensions/ directory on the filesystem, so you couldn't replace it by a symlink, right?

I think you made a typo that confused me : "Pacman does not complain about anything when installing test1 after test2"
Didn't you mean installing test2 after test1? Because that would try to replace the test/ directory by a test symlink.
Maybe it would be better if pacman just failed in this case indeed, instead of just ignoring it.

So in pacman code, that's case 11: existing dir, symlink in package, ignore it.
However, we can't easily fail here, because it happens during the extraction. We are back to the problem in  bug 7652 ,
where we would need a rollback system to handle this properly.
Comment by Aaron Griffin (phrakture) - Friday, 30 November 2007, 07:08 GMT
With  FS#8141  closed, is this closable?
Comment by Xavier (shining) - Friday, 30 November 2007, 07:49 GMT
I don't think so, the problem is that the current fileconflict checking is too basic :
libalpm/conflict.c :
396 if(S_ISDIR(lsbuf.st_mode)) {
397 _alpm_log(PM_LOG_DEBUG, "%s is a directory, not a conflict\n", path);

If a directory exists on the filesystem, it never treats it as a conflict, even if the package contains a file or a symlink of the same name.
It would probably be better to fail in this case, as mentioned in the title of this report.
Comment by Aaron Griffin (phrakture) - Friday, 30 November 2007, 17:07 GMT
ah, that seems easy enough to expand for the dir case
Comment by Xavier (shining) - Friday, 21 December 2007, 11:11 GMT
I believe this is another example of this situation :
Comment by Dan McGee (toofishes) - Sunday, 06 January 2008, 00:56 GMT
This is our only blocker for 3.1 release on the roadmap. Thoughts? Still an issue?
Comment by Xavier (shining) - Sunday, 06 January 2008, 10:34 GMT
Yes, it's still an issue, nothing happened there.
I just tried to hack something together.
I also had to fix a little problem in pactest that I noticed a while ago, and finally figured out.
Comment by Dan McGee (toofishes) - Sunday, 06 January 2008, 15:39 GMT
Those patches look sane to me, and it does fix the specific issue mentioned in this bug (although we still have issues with fileconflict001 and fileconflict002 pactests that already exist). OK to close if I pull these patches?
Comment by Xavier (shining) - Sunday, 06 January 2008, 16:13 GMT
The two first fileconflict pactests are not directly related to this bug.
As Nagy said, 001 might be fixed using realpath. I just gave it a try but failed. And 002 looks pretty hard to fix.

In any cases, these are different problems. So if you pull my patches, I think this bug can be closed.