I'd be very surprised if this wasn't a cause of many of our problems in Linux
too. I suspect a common case is someone querying the DB (`rpm -qa`) when an
transaction happens, and then theoretically-read-only operation ends up writing
stale data back, but I haven't actually had the time to sit
Um, *this* issue is about RPM behavior on OS X and a sandbox policy prohibiting
writes.
Open an issue with details with details about your Facebook problems if you
wish.
The output of db_stat showing the state of locks is usually the starting point
to identifying the root cause.
--
You are
Hence this Issue was filed. :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/232#issuecomment-365676303___
Rpm-maint mailing
@jayzmh: the issue with dcrpm is the costly detection and possibly imperfect
analysis of "bad actors" not how often db_recover is run. dcrpm is treating a
symptom rather than solving the root cause of whatever problem exists.
--
You are receiving this because you are subscribed to this
Before this commit, rpm simply did not take hardlinks into account when
calculating disk space requirements. This made it fail spectaculary for
packages that contain a high number of hardlinks, like glibc-locale.
We now "bind" the file size to the last hardlink member. This is still not
