darktable keeps losing my files forcing a re-import

Software darktable
12

It’s good that your DB looks healthy.
For running with -d common, I meant that you use that all the time and see if there’s a message when the problem occurs.

The mounting options you show look weird to me. According to the File System Hierarchy Standard, /mnt is for temporary mounts. I think that is the root of your problem.
If the generated IDs are not constant (and, given that those are for temporary mounts, they probably change all the time), then it appears files will appear at different paths at different times.

My mount points are not /mnt/some-generated-id, but rather concrete paths (as reported by the mount command):

  • /dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro) – the root of my file system (/), from the first partition of my SSD. System directories like /root, /etc, /bin, /sbin, /usr and /opt are stored on that partition.
  • /dev/sda2 on /home type ext4 (rw,relatime) – user directories, like /home/kofa, from the 2nd partition of my SSD
  • /dev/sdb2 on /oldhome type ext4 (rw,relatime) – this is a large HDD where I mostly keep photos and videos
  • /dev/sdc1 on /media/backup type ext4 (rw,relatime) – an external (USB-connected) drive with my backups.

What does the mount command print for you?

I’m old-fashioned and don’t know the GUI tools. The mount configuration shown above is the result of manual configuration. Normally, drives are mounted based on /etc/fstab. It’s a text file that you can edit, but you need root (admin) rights.

My fstab looks like this, explicitly specifying which partition appears where in the file system:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=b3646d97-a9f1-47e9-bb09-d6cfd8972ddd /               ext4    errors=remount-ro 0       1
# /home was on /dev/sda5 during installation
UUID=44fbed5b-641b-43f1-852c-fb89f72247a4 /home           ext4    defaults        0       2
# /oldhome was on /dev/sdc2 during installation
UUID=23acdf08-dad1-4666-9e0f-db88c2df0102 /oldhome        ext4    defaults        0       2
# /dev/sda6 swap SSD
UUID=e235e39e-3465-45d0-b332-4dcd9f9a9b34 none            swap    pri=100         0       0
# swap was on /dev/sdc1 during installation
#UUID=b87bd478-ea55-4e3a-83aa-c4951832175b none            swap    sw              0       0
# /dev/sdg1
UUID=b36c1873-2b3a-4e3d-92f8-89f1f442b5e5 /media/backup ext4 defaults

You can check which cryptic ID (in the Identify As fields of your screenshot) maps to which disk and which partition with ls -l /dev/disk/by-uuid/:

root@eagle:~# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Jan 12 16:30 23acdf08-dad1-4666-9e0f-db88c2df0102 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Jan 12 16:30 44fbed5b-641b-43f1-852c-fb89f72247a4 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan 12 16:30 b3646d97-a9f1-47e9-bb09-d6cfd8972ddd -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 12 16:30 b36c1873-2b3a-4e3d-92f8-89f1f442b5e5 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jan 12 16:30 b87bd478-ea55-4e3a-83aa-c4951832175b -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jan 12 16:30 e235e39e-3465-45d0-b332-4dcd9f9a9b34 -> ../../sda3

sda/b/c are the disks. sdx1/2/3 are partitions on disk x.

The advantage of the UUIDs is that if I move the physical disk to another connection (another cable), the UUID stays the same, even though sda may become sdc, if I understand correctly.

1 Like