pacman 5.0.1-4. I've two filesystems, / and /home. Overnight recently, a download-only of packages filled / so I created /home/var-cache, moved /var/cache's contents there, and made a /var/cache be a symlink. Everything continued working fine, including non-pacman users of /var/cache. The next evening, last night, four packages were downloaded into /home filesystem:

:: Retrieving packages...
downloading fakeroot-1.21-2-x86_64.pkg.tar.xz...
downloading fontconfig-2.12.1-3-x86_64.pkg.tar.xz...
downloading mesa-12.0.1-6-x86_64.pkg.tar.xz...
downloading python-setuptools-1:25.1.6-1-any.pkg.tar.xz...

The problem appeared when I tried to install these:

$ sudo -i pacman -Su
[sudo] password for ralph:
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (4) fakeroot-1.21-2 fontconfig-2.12.1-3 mesa-12.0.1-6
python-setuptools-1:25.1.6-1

Total Installed Size: 39.16 MiB
Net Upgrade Size: -0.10 MiB

:: Proceed with installation? [Y/n]
(4/4) checking keys in keyring [######################] 100%
(4/4) checking package integrity [######################] 100%
(4/4) loading package files [######################] 100%
(4/4) checking for file conflicts [######################] 100%
(4/4) checking available disk space [######################] 100%
:: Processing package changes...
(1/4) upgrading fakeroot [######################] 100%
error: cannot remove /var/cache/ (Not a directory)
(2/4) upgrading fontconfig [######################] 100%
updating font cache... done.
error: could not open file /var/cache/pacman/pkg/mesa-12.0.1-6-x86_64.pkg.tar.xz:
No such file or directory
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.
$

The log file says:

[2016-08-07 10:57] [PACMAN] Running 'pacman -Su'
[2016-08-07 10:57] [PACMAN] starting full system upgrade
[2016-08-07 10:58] [ALPM] transaction started
[2016-08-07 10:58] [ALPM] upgraded fakeroot (1.21-1 -> 1.21-2)
[2016-08-07 10:58] [ALPM] error: cannot remove /var/cache/ (Not a directory)
[2016-08-07 10:58] [ALPM] upgraded fontconfig (2.12.1-1 -> 2.12.1-3)
[2016-08-07 10:58] [ALPM-SCRIPTLET] updating font cache... done.
[2016-08-07 10:58] [ALPM] transaction failed

It's the aftermath that's odd, and left me with broken packages.

/var/cache had been removed by something, despite the "cannot remove" above, and re-created as a directory. In it was just the fontconfig directory, containing a few files that were already in the "real" version sitting in /home. This mean /var/cache/pacman "disappeared" mid upgrade as far as pacman was concerned.

/var/lib/pacman/local/mesa-12.0.1-6/ was left with no files, though `pacman -Q mesa' said it was the installed version. Attempting `pacman -Su' detected this:

:: Starting full system upgrade...
resolving dependencies...
error: could not open file /var/lib/pacman/local/mesa-12.0.1-6/desc: No such file or directory
looking for conflicting packages...

Packages (1) python-setuptools-1:25.1.6-1

That only one package is left suggests it thinks the other three installed OK. `pacman -Qk' only complained about mesa.

At this point, trying to do things to investigate was hampered, e.g.

error while loading shared libraries: libEGL.so.1: cannot open shared object file:
No such file or directory

I resolved the problem by -Rdd mesa, followed by -S mesa. -Qk then complained about problems with nvidia-304xx-libgl so that was -S too. -qQkk's is now as expected.

Several thoughts... The symlink shouldn't be removed, especially as it wasn't /var/cache/pacman but the directory above. The error during fakeroot's upgrade, 1/4, didn't stop /var/cache being mkdir'd and /var/cache/fontconfig, 2/4 from being created. The disappearance of /var/cache/pacman during the upgrade caused mesa, 3/4, to have no files in /var/lib/pacman/local/mesa-12.0.1-6. The Linux FHS says "The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage)." — http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA To me, that includes during an upgrade! :-) If it needs them to persist then perhaps they should be sat elsewhere.