"cp: cannot create regular file..." during Registering files phase about aconfmgr HOT 10 CLOSED

Hmm. Not sure what could have caused that, since we explicitly create that directory before copying the file there.

If you're interested in helping tracking this down, you could check if it's reproducible with every run. You could probably ignore other paths to avoid having to wait a few hours for it to get to that point.

Practically speaking, though, you may want to heed the software's warning and start your configuration with adding ignores for those paths. The "ignoring files" section of the documentation incidentally uses ignore rules for those locations as an example.

from aconfmgr.

:: Registering files...
::: Found 36877 new and 0 changed files.
cp: cannot create regular file '/home/milk/.config/aconfmgr/files//usr/share/avant-window-navigator/awn-settings/awnClass.pyc': No such file or directory
:::: Fatal error! Stack trace:
::::: /usr/lib/aconfmgr/save.bash:1 [AconfSave]
::::: /usr/lib/aconfmgr/main.bash:152 [Main]
::::: /usr/lib/aconfmgr/main.bash:169 [source]
::::: /usr/bin/aconfmgr:26 [main]
aconfmgr save  1420.97s user 3197.81s system 59% cpu 2:08:52.11 total

awnClass.pyc exists both in the original location and the aconfmgr TMPDIR

from aconfmgr.

The error message implies that the target directory that cp is trying to copy to doesn't exist, however, it does.

From the information available, and considering that the error appears random (a different file path than your first run), the most likely explanation seems to be a random filesystem failure, resulting in an inconsistent view of the filesystem.

What disk filesystem are you using?

Are you using any layers like FUSE, NFS, unusual mount options?

Any software that interferes with the filesystem, like resident anti-virus programs?

from aconfmgr.

LVM2 RAID with ext4, mounted in fstab.

No AV or filesystem changing software active.

Only 'oddity' is that I'm running it through sudo -E /bin/zsh to avoid missing password prompts.

This is confusing as heck :(

from aconfmgr.

I've since tried using from a bash root prompt, as well as symlinking /root/.config/aconfmgr to a couple of new drives that are LVM2 RAIDed that I installed just three months ago, as well as setting the $TMPDIR to a location on the same new drive, but there was no change in the style of error, just a different file.

Saying that, I haven't seen exactly if the "stack trace" comes immediately after the cp error. There's still the possibility this is two errors..

:: Registering files...
::: Found 36870 new and 0 changed files.
cp: cannot create regular file '/root/.config/aconfmgr/files//usr/lib32/gio/modules/giomodule.cache': No such file or directory
:::: Fatal error! Stack trace:
::::: /usr/lib/aconfmgr/save.bash:1 [AconfSave]
::::: /usr/lib/aconfmgr/main.bash:152 [Main]
::::: /usr/lib/aconfmgr/main.bash:169 [source]
::::: /usr/bin/aconfmgr:26 [main]

$ ll /home/milk/sounds/tmp/aconfmgr-root/system/files/usr/lib32/gio/modules/giomodule.cache

-rw-r--r-- 1 root root 150 Dec 20 21:19 /home/milk/sounds/tmp/aconfmgr-root/system/files/usr/lib32/gio/modules/giomodule.cache

from aconfmgr.

Do you think you could reproduce this problem in a virtual machine, or another replicatable controlled environment?

Perhaps the strace output will contain some clues. Maybe try strace -ttf -o >(tail -n 10000 > aconfmgr.trace) bash ./aconfmgr save and check/upload aconfmgr.trace?

from aconfmgr.

Saying that, I haven't seen exactly if the "stack trace" comes immediately after the cp error. Threre's still the possibility this is two errors..

That's true. I pushed a change that should result in more precise stack traces (no more spurious ":1" as the line number).

from aconfmgr.

So I somehow managed to somehow mess up the previous diagnostic because I checked the setup after and the symlink for the /root/.config/aconfmgr to /home/milk/sounds/tmp was not a symlink.

I fixed this to actually point at my new mirrored drive(s), as with $TMPDIR, ran aconfigmrg save from scratch, and it worked, so it turns out this is actually two issues (or possibly 1.5 issues).

...
:: Registering files...
::: Found 36870 new and 0 changed files.
cp: cannot create regular file '/root/.config/aconfmgr/files//var/lib/dkms/vboxhost/5.0.14/4.3.4-1-ck/x86_64/log/make.log': No such file or directory
cp: cannot create regular file '/root/.config/aconfmgr/files//var/lib/pacman/local/haskell-esqueleto-2.5.3-29/desc': No such file or directory
cp: cannot create regular file '/root/.config/aconfmgr/files//var/lib/pacman/local/python-pbkdf2-1.3-3/desc': No such file or directory
cp: cannot create regular file '/root/.config/aconfmgr/files//var/lib/pacman/local/python-pbkdf2-1.3-3/files': No such file or directory
cp: cannot create regular file '/root/.config/aconfmgr/files//var/lib/pacman/local/python-pbkdf2-1.3-3/mtree': No such file or directory
:::: Done.
::: Done.
:: Registering file properties...
::: Comparing file properties...
:::: Done.
::: Done.
:: Done (configuration changed).

I'll run it again at some point soon with the older drive(s) to see what the error output is. Possibly maybe, given the massive amount of I/O, it's a race condition from a slow response time or an underlying error on one of the the two older mirrored drives (SMART gives errors a couple of errors though no big warnings).

Indeed, if the copy of the original file from / partition on the old drive(s) to $TMPDIR fails, there would be no $TMPDIR file to copy from, thus the errors..

from aconfmgr.

Indeed, if the copy of the original file from / partition on the old drive(s) to $TMPDIR fails, there would be no $TMPDIR file to copy from, thus the errors..

That may be true if not for that the error message is specifically complaining about the destination path not existing, and that aconfmgr re-enumerates the files in $TMPDIR when copying them to the configuration.

from aconfmgr.

I seem to have considered previously that there was something to improve here, however, I don't remember what that is, and from re-reading this issue and looking at the code again, I don't see how this problem can occur (from a fault in aconfmgr), nor how I would reproduce it... so, I'm going to close this issue, but let's reopen if this occurs again, or if there is something actionable here that I missed.

from aconfmgr.