[pacman-dev] Orphaning files in the filesystem after unsuccessful pacman -R

[Allan McRae]

On 22/01/14 06:01, Nagy Gabor wrote:
>> Hello,
>>
>> It seems I found a bug in pacman. Some information first:
>>   version: pacman 4.1.2-5 prebuilt from official repo
>>    system: Linux 3.12.7-2-ARCH i686
>>
>> So it happened when I tried to remove alex package.
>>
>> $ sudo pacman -R alex
>>     [sudo] password for michael:
>>     checking dependencies...
>>
>>     Packages (1): alex-3.1.3-1
>>
>>     Total Removed Size:   1.18 MiB
>>
>>     :: Do you want to remove these packages? [Y/n] y
>>     error: cannot remove file '/usr/': Read-only file system
>>     ldconfig: Can't create temporary cache file /etc/ld.so.cache~:
>> Read-only file system
>>     error: command failed to execute correctly
>>
>> Uhm... I forgot I have root filesystem mounted read-only. No problem.
>>
>> $ sudo mount / -o remount,rw
>> $ sudo pacman -R alex
>>     error: target not found: alex
>>
>> What? How could pacman remove the package from a read-only filesystem?
> 
> Well, pacman just removed the database entry (from the
> writeable /var/lib/pacman/)...
> This behaviour is clearly odd here, but it is not easy to say what is
> the expected behaviour in general, for example, what should we do when
> only ONE file cannot be removed? AFAIK, pacman cannot "undo"
> transaction after it has been started atm (transaction rollback is not
> implemented), so the only options are "pre-remove check" or stop.
> 
> Theoretically, pacman should collect "file foo has become untracked due
> to a removal error" somehow (for example, we could rename the package to
> alex-garbage in the database, keeping the non-removed files in its
> filelist), but that would definitely violate KISS and it would be not so
> easy to implement (directories are also listed in the filelist of a
> package, possible conflicts of garbage packages, etc.).
> 
> I cannot see a clean "filesystem check" solution neither.
> 

I can...   we already check if a filesystem is read-only during an
install/upgrade (with the DiskSpace option).

I think it would be quite simple to add a check before any package
removal starts.

I have opened a bug to track this:
https://bugs.archlinux.org/task/38615

Allan