Arch Linux

schard

Member

From: Hannover

Registered: 2016-05-06

Posts: 1,726

Website

core.db is a directory

On a few systems, while upgrading, I got the following error:

130 ✗ 1282 ~ $ LANG=C pacman -Syu 
:: Synchronizing package databases...
 core.db failed to download
error: could not rename /var/lib/pacman/sync/core.db.part to /var/lib/pacman/sync/core.db (Is a directory)
error: failed to synchronize all databases (unexpected error)
1 ✗ 1282 ~ $ LANG=C rm /var/lib/pacman/sync/core.db
rm: cannot remove '/var/lib/pacman/sync/core.db': Is a directory
1 ✗ 1282 ~ $ LANG=C rmdir /var/lib/pacman/sync/core.db
0 ✓ 1282 ~ $ LANG=C pacman -Syu 
:: Synchronizing package databases...

As I could already solve this problem as per above, my question is whether this is or was a known bug in pacman, or whether a broken mirror causes this issue.
And how can I prevent this error in the future?

Stefan Husmann

Member

From: Germany

Registered: 2007-08-07

Posts: 1,332

Re: core.db is a directory

Does this happen in all shells or only in nushell?

schard

Member

From: Hannover

Registered: 2016-05-06

Posts: 1,726

Website

Re: core.db is a directory

I do not use nushell on the respective systems, but bash.
The above output is from the SSH login shell (bash).

seth

Member

Registered: 2012-09-03

Posts: 38,677

Re: core.db is a directory

Custom xfer agent?
AUR helper?

Otherwise I'd bet on the mirror, => use reflector?
If this is a frequent issue, audit access to the file.
If you still have some compromised paths (w/ dir) you could compare the timestamp w/ the pacman log to see whether this actually happened around an update (or maybe sth. entirely different changes the path)

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Your xinitrc is broken

schard

Member

From: Hannover

Registered: 2016-05-06

Posts: 1,726

Website

Re: core.db is a directory

Custom xfer agent?

Nope.

AUR helper?

Neither.

Otherwise I'd bet on the mirror, => use reflector?

Already using it.

If this is a frequent issue, audit access to the file.

It only happened once on this very system, but I will audit the file nonetheless.

If you still have some compromised paths (w/ dir) you could compare the timestamp w/ the pacman log to see whether this actually happened around an update (or maybe sth. entirely different changes the path)

Will check once the system is online again. Currently it's down.