Open tobiaslangner opened 8 years ago
Hmm, does this happen with other dotfiles also?
Hello Thomas, I think that the problem has nothing to do with dot files, I just randomly picked a file to demonstrate the problem. When I mount the mentioned archive, it does not even contain the folder media/sync, let alone the files within. The call that I used to create the archive is something along the lines of
attic create $ARCHIVE / /media/sync ... --do-not-cross-mountpoints
where /media/sync is a mountpoint of some device (Do I have to add a trailing slash to '/media/sync' to make sure it is added?). When inspecting the deduplicated sizes of the recent archives through attic info, I can see a significant increase in the size of the latest archive (which is supposed to contain the newly added directory, which is not visible in the mounted archive) and given the fact that I can extract them from the archive, I guess that they are actually there. The only issue seems to be that they are not visible when using attic-mount...
Can you write a minimal script that reproduces this?
It would be nice if the upper directory is not /, but something like "input" or "/tmp/input", mount point should be "mnt" or "/tmp/mnt". You can use sudo and mount -t tmpfs. "touch filename" to create empty files.
Hey Thomas, thanks for your reply and sorry for the long delay, I was on holidays. I tried reproducing the behavior along the lines of what Voltara did in the borg-report, but I failed to reproduce the problem for quite a while. Then I looked more closer at what Voltara had done and, indeed, it seems that the order in which the directories are passed to attic-create is relevant for reproducing the bug. The following script shows the bug on my machine running attic 0.16:
#!/bin/bash
set -e
TMPDIR=$( mktemp -d )
cd $TMPDIR
# Prepare filesystem
mkdir -p fs/mnt
sudo mount -t tmpfs -o size=1M tmpfs fs/mnt
echo "first test file " > fs/mnt/test1
echo "second test file" > fs/test2
# Prepare repository
attic init repository
# Make backup
attic create --do-not-cross-mountpoints repository::test fs/mnt fs
# Unmount sshfs mount
sudo umount fs/mnt
# Mount the stuff and check the file
mkdir mnt
attic mount repository::test mnt
echo "Mount:"
find mnt -ls
fusermount -u mnt
# Extract the file
mkdir extraction
cd extraction
attic extract ../repository::test fs/mnt/test1 fs/test2
cd ..
echo "Extraction:"
find extraction -ls
Note that changing the backup line to attic create --do-not-cross-mountpoints repository::test fs fs/mnt
(i.e., putting the parent directory fs first) lets the bug disappear.
I went back to my server and checked the order of the directories there and indeed, the parent directory was also last there.
@tobiaslangner borg dev @enkore could find / fix it (in borg, but you could use same patch for attic I guess), see the link to the closed issue right above your post.
Recently, I wanted to check that some newly added files are present in my latest attic backup and to that end mounted the latest backup to a local directory (
attic mount
). To my surprise, the files in question where not present in the mounted archive. I picked one particular file that should have been present and tried extracting it throughattic extract
and to my even greater surprise, the file was extracted correctly. Here is the exact series of commands I entered (as root user):I expected that both methods allow me to access said file. If this is the case, then something is wrong and should be fixed, as
attic mount
is my preferred way to verify that certain files have properly been backed up.Let me know if I can provide additional information or assist in any other way.