CRUX

Welcome to CRUX bug tracking.
Tasklist

FS#1888 - pkgadd ruins files with 'INSTALL' event

Attached to Project: CRUX
Opened by Feodor Petrov (teodor) - Wednesday, 22 September 2021, 14:21 GMT
Last edited by Tim Biermann (tb) - Saturday, 12 March 2022, 08:58 GMT
Task Type Bug Report
Category tools → pkgutils
Status Closed
Assigned To CRUX Developers (crux)
Operating System CRUX
Severity Low
Priority Normal
Reported Version 3.6
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

When there is a rule like
INSTALL ^etc/.*$ NO
pkgadd erases already existing files in /etc/!
And it even does not create files in /var/lib/pkg/rejected/!
This task depends upon

Closed by  Tim Biermann (tb)
Saturday, 12 March 2022, 08:58 GMT
Reason for closing:  Invalid
Comment by Tim Biermann (tb) - Thursday, 23 September 2021, 17:42 GMT
Hi teodor,

I can reproduce that. However, is there a reason why you would change UPGRADE (default) to INSTALL in the first place?

"man 8 pkgadd" clears up the difference between the two options. Is this really a bug, or a misconception?
Comment by Feodor Petrov (teodor) - Sunday, 26 September 2021, 16:09 GMT
It is definitely a bug. If a file exists in a directory for some reason, it shouldn't be deleted! It erases your file, you lost your data. It even does not creates new nor in /etc/ nor in /var/lib/pkg/rejected/!

For example, use case is when you roll new core in --install-root=/dir/, then you run a script, which migrates all config files from one system to another, then you chroot into new core and proceed installing remaining ports in the new system. My 'mig' script copies all configs from a custom list from origin directory to destination, so new core gets configs for all programs, even those, which is not yet present in the new system.
Comment by Tim Biermann (tb) - Sunday, 26 September 2021, 16:44 GMT
Well, okay. Given the fact that it drops existing configs might be undesired behaviour.
I have to say that I have a rather expansive pkgadd.conf on my systems tailored to my needs, but it always uses UPGRADE directives, never INSTALL..

Anyway, feel free to propose a patch for it. I'll need a few months before I can dive into that kind of work with CRUX because of other personal projects that are more important right now.
Comment by John McQuah (farkuhar) - Friday, 11 February 2022, 12:28 GMT
I haven't been able to reproduce this bug.

1. I mounted an older CRUX installation at /mnt, then appended to the end of /mnt/etc/pkgadd.conf the rule from the original bug report.
2. I rebuilt pkgadd after commenting out CXXFLAGS += -NDEBUG, then put the resulting binary in a separate directory and prepended the directory to root's $PATH.
2. I tried both `pkgadd --root /mnt `, and pkgadd after chrooting to /mnt.
3. In both cases the installation proceeded without erasing any of the existing content in /mnt/etc.
4. The debug version didn't reveal any suspiciously-large sets of regex matches under "Install set" or "Non-Install set". The strace never showed a search of the filesystem to determine files that should be removed upon an INSTALL event.

Was this bug silently fixed in the months since the original report? If it's no longer happening, this issue should be closed. I've been searching up and down pkgadd.cc and pkgutils.cc, only ever finding iterators that go through the package archive to build the keep_list and non_install_list. Even when I manually created a file in /mnt/etc that would have been clobbered by the package footprint, the installation proceeded without destroying that file. I admit I might lack the imagination to see how unlink() would ever be called on a file unrelated to the package (either through its archive contents, or through /var/lib/pkg/db). But maybe some gcc voodoo was translating the source code to undesired machine instructions, and a more recent version of gcc doesn't make that mistake.

Loading...