FS#20894 - [filesystem] (2010.09-1 -> 2010.07-1) produces error with mounted cd

Attached to Project: Arch Linux
Opened by jwbirdsong (jwbirdsong) - Sunday, 19 September 2010, 23:23 GMT
Last edited by Allan McRae (Allan) - Friday, 03 December 2010, 14:27 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Pierre Schmitz (Pierre)
Thomas Bächler (brain0)
Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
As title says; recent update if filesystem pkg fails IF you have a cd mounted.

I asked around (IRC) before filing to see if this was expected behaviour. I can see it going either way.

Pacman error attached.

Please forgive if this is expected.


Steps to reproduce:
mount a data cd and update 'filesystem' package
   err (0.9 KiB)
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 03 December 2010, 14:27 GMT
Reason for closing:  Fixed
Additional comments about closing:  filesystem-2010.10-1
Comment by Pierre Schmitz (Pierre) - Monday, 20 September 2010, 06:18 GMT
I am able to reproduce it. However, my update didn't cause this. Maybe pacman tries to remove and recreate that dir for some reason. (filelist and permission of the old and new package are identical)
Comment by Pierre Schmitz (Pierre) - Monday, 20 September 2010, 06:19 GMT
adding more guys; not sure if this is a packaging or pacman issue.
Comment by Allan McRae (Allan) - Monday, 20 September 2010, 06:35 GMT
So an upgrade operation is just a remove followed by an install. Pacman is seeing /media/cd/ as empty so attempting to remove the directory before creating it again. Not sure why pacman is seeing that directory as empty when a data CD is mounted.
Comment by Pierre Schmitz (Pierre) - Monday, 20 September 2010, 06:39 GMT
In this case it is harmless anyway.

However, in general I think directories like /media/cd or /media/fd shouldn't be provided by the filesystem package.
Comment by Allan McRae (Allan) - Wednesday, 06 October 2010, 14:06 GMT
Looking into this, it is because /media/cd becomes ro when a cd gets mounted. Pacman checks all files/folders that are being updated are rw (excluding files in the backup array which do not get touched).

Two options to fix:
1) remove those folders from the filesystem package (as Pierre suggests)
2) from the pacman side: Perhaps directories that are in both the old and new packages should be skipped in the rw check. We do not fail on an attempted delete of a directory anyway as we assume it contains files from other packages. But it will give the usual directory permissions differ blurb.

These options do not clarify whether it is a packaging issue or a pacman issue or both...
Comment by Dan McGee (toofishes) - Wednesday, 06 October 2010, 14:12 GMT
We'd lose the whole benefit of this checking if we went with 2. It is there so one can be notified if say /var/lib/privatedata is 700 in the package but 755 on your filesystem. Chances of this folder being new are not that high.
Comment by Allan McRae (Allan) - Wednesday, 06 October 2010, 14:33 GMT
Not that checking. Just the checking in "can_remove_file" in lib/libalpm/remove.c

/* If we fail write permissions due to a read-only filesystem, abort.
* Assume all other possible failures are covered somewhere else */

We could skip that check for _folders_ that are in both the old and the new package as they do not need removed.

Edit: or at least it does not matter if they are failed to be removed as is shown later in remove.c...

if(S_ISDIR(buf.st_mode)) {
if(rmdir(file)) {
/* this is okay, other packages are probably using it (like /usr) */
...
Comment by Dan McGee (toofishes) - Wednesday, 06 October 2010, 14:38 GMT
Aha! Yes, that is correct.
Comment by Pierre Schmitz (Pierre) - Sunday, 24 October 2010, 09:29 GMT
I have removed the /media/* mount points for the next filesystem release.
Comment by Pierre Schmitz (Pierre) - Thursday, 18 November 2010, 13:11 GMT
Can we close this or move it to the pacman bug tracker then?
Comment by Allan McRae (Allan) - Friday, 03 December 2010, 14:26 GMT
Opened  FS#21971  for tracking this in pacman.

Loading...