Arch Linux

IIRC disk space checking was temporarily removed because it was not done right anyway.

Roman- this isn't quite what that was, however.

Can you reproduce this by chance with --debug or --debug=3 output? That would probably be helpful.

The relevant part with --debug=3 is:

error: could not extract /testdir/141/testfile (No such file or directory)
debug: logaction called: error: could not extract /testdir/141/testfile (No such file or directory)
debug: decompression progress: 91.370011% (108416 / 118656)
debug: extracting /testdir/291/
error: could not extract /testdir/291/ (No space left on device)
debug: logaction called: error: could not extract /testdir/291/ (No space left on device)
debug: decompression progress: 91.370011% (108416 / 118656)
debug: extracting /testdir/291/testfile
error: could not extract /testdir/291/testfile (No such file or directory)
debug: logaction called: error: could not extract /testdir/291/testfile (No such file or directory)
error: errors occurred while installing mydummy
debug: logaction called: errors occurred while installing mydummy
debug: updating database
debug: adding database entry 'mydummy'
debug: writing mydummy-1-1 DESC information back to db
error: could not open file /var/lib/pacman/local//mydummy-1-1/desc: No such file or directory
error: could not update database entry mydummy-1-1
debug: logaction called: could not update database entry mydummy-1-1
debug: returning error 14 from _alpm_add_commit : could not update database
debug: returning error 22 from alpm_db_unregister : transaction already initialized
debug: removing DB current, 3 remaining...
debug: returning error 22 from alpm_db_unregister : transaction already initialized
debug: removing DB current, 3 remaining...
debug: returning error 22 from alpm_db_unregister : transaction already initialized
debug: removing DB current, 3 remaining...
debug: returning error 22 from alpm_db_unregister : transaction already initialized
debug: removing DB current, 3 remaining...


Last 2 lines are repeating forever.
One more remark, I have all on one filesystem (ext3) except the /home

I already mentioned this issue on the ML, pacman will loop each time a transaction fails :
http://www.archlinux.org/pipermail/pacman-dev/2007-July/008726.html
last patch I proposed :
http://www.archlinux.org/pipermail/pacman-dev/2007-July/008970.html
However, nobody commented on the issue or reviewed the patch I proposed.

But that only explains the looping, and it's more general than this no space left issue.
If the partition gets filled while pacman is installing a package, it'll most likely result in a not so clean state : package half extracted, entry not added to database,...
But freeing some space and reinstalling the package should fix everything.

This comes down to the whole concept of a true transaction, which we don't currently do. Until then, I don't know how much we can do about this. Xavier and Aaron, any comments?

My only comment is this line here:

error: failed to release transaction (could not commit transaction)

That just seems silly. If release can't commit it, it should still be able to release it, yes?

This makes me think of java's File.close() functions which throw exceptions - wtf is the point?

Btw, the loop problem should be fixed now in git (this wasn't mentioned yet in this bug report).

I made a few commits for fixing this bug, but then found a better solution, which mostly reverted my previous commits :
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=b0aa51059233849b0a7ef8d6a851750776ce6645

I believe that the above message : "error: failed to release transaction (could not commit transaction)"
was caused by the trick to handle interrupted transaction with ctrl+c.

I moved this code to a new alpm_trans_interrupt() function, so alpm_trans_release() shouldn't fail because of that anymore.
However, alpm_trans_release() still has sanity checks, so it can still fail. Not sure if it's a big problem..


About the actual disk space problem, I don't really have an opinion. It's probably rather a long term fix indeed :P

btw check this out: http://bugs.archlinux.org/task/11639