Comment 2 for bug 1728548

When I try "deja-dup --backup" on the command line, I get a message that it is a "creating a fresh backup to protect against backup corruption. This will take longer than normal".

I ran the process with `strace`, saved the output to a logfile, and waited several hours for the crash to happen again. Then I went to review the 29G file that had been generated.

Ignoring the flood of polling related entries, I focused on noting the last files that were accessed before the process crashed. Here are those last related lines of the `strace` output:

```
statfs("/home/mark/.local/share/gvfs-metadata", {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=50211842, f_bfree=9505
524, f_bavail=6949148, f_files=12763136, f_ffree=11482383, f_fsid={val=[3791877080, 1636325322]}, f_namelen=255, f_frsi
ze=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
openat(AT_FDCWD, "/home/mark/.local/share/gvfs-metadata/home", O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0600, st_size=337916, ...}) = 0
mmap(NULL, 337916, PROT_READ, MAP_SHARED, 16, 0) = 0x7fec716eb000
statfs("/home/mark/.local/share/gvfs-metadata", {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=50211842, f_bfree=9505
524, f_bavail=6949148, f_files=12763136, f_ffree=11482383, f_fsid={val=[3791877080, 1636325322]}, f_namelen=255, f_frsi
ze=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
openat(AT_FDCWD, "/home/mark/.local/share/gvfs-metadata/home-b5c635b8.log", O_RDONLY) = 18
fstat(18, {st_mode=S_IFREG|0644, st_size=32768, ...}) = 0
mmap(NULL, 32768, PROT_READ, MAP_SHARED, 18, 0) = 0x7fec80007000
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 20
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x55972ecd5490, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55972ecc0810, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55972eccc0c8, FUTEX_WAKE_PRIVATE, 1) = 1
read(20, "\1\0\0\0\0\0\0\0", 16) = 8
write(20, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x55972f0a0fe0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
close(20) = 0
unlink("/home/mark/.cache/deja-dup/metadata") = -1 EISDIR (Is a directory)
rmdir("/home/mark/.cache/deja-dup/metadata") = 0
lstat("/home/mark/.cache/deja-dup", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/mark/.cache", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat("/home/mark", {st_mode=S_IFDIR|0755, st_size=24576, ...}) = 0
lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
```

So it looks like the GVFS metadata file was the last one to be accessed. I presume the `unlink` and `rmdir` calls are part of a clean-up at the end and happened after the error.

Now I need to shop for a new backup solution!