Hi all,
FIXED!
So, what’s happening:
In /usr/share/yunohost/helpers.d/filesystem:
In the function ynh_restore_file:
# Do a copy if it's just a mounting point
if mountpoint -q $YNH_BACKUP_DIR; then
if [[ -d "${ARCHIVE_PATH}" ]]; then
ARCHIVE_PATH="${ARCHIVE_PATH}/."
mkdir -p "$DEST_PATH"
fi
cp -a "$ARCHIVE_PATH" "${DEST_PATH}"
# Do a move if YNH_BACKUP_DIR is already a copy
else
mv "$ARCHIVE_PATH" "${DEST_PATH}"
fi
AHAH!
ARCHIVE_PATH="${ARCHIVE_PATH}/."
So that’s where it comes from!
I’m not proficient in bash, so I can only speculate there was a good reason for that to be there.
But since there’s a backup involving mv instead of a failing cp due to the “/./” in the path, I went for the simplest:
apt remove archivemount
Then I tried to restore again, and it worked! Actually it was much faster to restore successfully than to fail with the mount…
Of course, I’ve been in this for 3 days, and only now that I zeroed down on archivemount did I find…
https://forum.yunohost.org/t/problem-in-restoring-apps/3238/2
And that’s very very exactly the same issue…
I don’t know if archivemount is required or useful for anything else, but if not, could it be banned by adding a dependency conflict with yunohost?