FS#7652 - libalpm check for ability to remove file is wrong, pacman runs into a loop when this gets triggered
Attached to Project:
Pacman
Opened by Jan de Groot (JGC) - Monday, 23 July 2007, 16:57 GMT
Last edited by Dan McGee (toofishes) - Monday, 03 December 2007, 04:22 GMT
Opened by Jan de Groot (JGC) - Monday, 23 July 2007, 16:57 GMT
Last edited by Dan McGee (toofishes) - Monday, 03 December 2007, 04:22 GMT
|
Details
in libalpm/remove.c, there's a function that checks if it's
possible to delete a file. This check fails on FreeBSD, and
actually, this check isn't sane:
if(access(file, W_OK) == -1) { if(errno != EACCES && access(file, F_OK) == 0) { First of all, deleting a file is not the same as writing a file. Deleting the file means writing the parent directory. On FreeBSD, this check returns ETXTBSY because the "text file" is "busy" (pacman or bash). This is also the documented behaviour in linux glibc, but somehow it doesn't happen there (bad glibc!). I modified the check to ignore ETXTBSY also in the 2nd line, pacman can upgrade pacman and bash safely on FreeBSD now. At the moment pacman runs into this error, pacman goes into a loop to clear the internal error state, pacman can only be interrupted with CTRL+\ (SIGQUIT). |
This task depends upon
Closed by Dan McGee (toofishes)
Monday, 03 December 2007, 04:22 GMT
Reason for closing: Fixed
Additional comments about closing: ETXTBSY check was added, closing.
Monday, 03 December 2007, 04:22 GMT
Reason for closing: Fixed
Additional comments about closing: ETXTBSY check was added, closing.
http://www.archlinux.org/pipermail/pacman-dev/2007-August/009084.html
That's not the real issue this bug report is about though, so I'll stop hijacking it now.
http://www.archlinux.org/pipermail/pacman-dev/2007-August/009150.html
What we really need is to do real transactional logic and NOT make this check at all, but rollback on failure.
I also think there is no easy fix, and the best thing to do would be to rollback on failure.
The loop was fixed, and the check was sligthly modified so that it also works on freebsd, but according to JGC, that check is still wrong.
But if you want to close this bug report, I can't prevent you from doing it anyway :)
Jan: I think Eliott has been working with Dan to get pacman working on FreeBSD and OSX. Last I heard, all expected pactests worked fine.
Jan, because you opened it, I'll wait for your word to close this bug
See here (you really only need the libdownload->libfetch patch):
http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=shortlog;h=freebsd