DSBMD system volume information

[BostonBSD]

I've been using dsbmd for several years and I've noticed that sometimes it doesn't finish writing system volume information before an unmount, leaving regular mounts with only a partial listing of the file system [fat32 filesystem]. The result appears like this:

myname@BostonBSD /m/gmounts> ls
ls: Recipes: No such file or directory
ls: books: No such file or directory
ls: fbsd: No such file or directory
ls: nomadBSD: No such file or directory
ls: perl: No such file or directory
SYSTEMS    plans wallpapers

myname@BostonBSD /m/gmounts [1]> sudo ls
Recipes        books        plans    perl
SYSTEMS        fbsd        nomadBSD    wallpapers

=======
DSBMD can still read the volume correctly, however, other mounting daemons cannot.
[the superuser can see the listing correctly, but cannot access the questionable files without dsbmd].

I posted this issue in a FreeBSD forum for further explanation.

I like dsbmd, but this issue has kept creeping up on me over the last few years and I'm wondering if it's correctable [I've never experienced it with any other mounting daemon, so far as I am aware].
dsbmd vs thunar

====
In order to fix this problem, I have to use DSBMD to copy the files to the hard drive, then use a different mounting daemon to write the files back to the USB drive [otherwise they stay listed as a sort of ghostfile]

[I never needed the FUSE kernel module with DSBMD and it wasn't loaded then, perhaps that makes a difference?]

[mrclksr]

Hi there @BostonBSD,

this is very odd.

I've been using dsbmd for several years and I've noticed that sometimes it doesn't finish writing system volume information before an unmount, leaving regular mounts with only a partial listing of the file system [fat32 filesystem].

Just to clarify:
DSBMD doesn't write anything to your storage media. Basically, it just checks for new media, determines its filesystem type, and mounts it if requested. It just automates the steps a user would take to mount a filesystem.

It took me many tries to reproduce your problem, and I found out, that those problematic directories (root2 in the example below) have lowercase short names, unlike the other entries, which have an entry for a long name, followed by an uppercase short name entry.

00000000  41 72 00 6f 00 6f 00 74  00 31 00 0f 00 f5 00 00  |Ar.o.o.t.1......|
00000010  ff ff ff ff ff ff ff ff  ff ff 00 00 ff ff ff ff  |................|
00000020  52 4f 4f 54 31 20 20 20  20 20 20 10 00 c0 1b 84  |ROOT1      .....|
00000030  2f 52 2f 52 00 00 1b 84  2f 52 03 00 00 00 00 00  |/R/R..../R......|
00000040  72 6f 6f 74 32 20 20 20  20 20 20 10 00 a0 44 60  |root2      ...D`|
00000050  30 52 30 52 00 00 44 60  30 52 04 00 00 00 00 00  |0R0R..D`0R......|

Can you confirm that?

# icat /dev/da0s1 2 | hd

icat is part of sysutils/sleuthkit

[I never needed the FUSE kernel module with DSBMD and it wasn't loaded then, perhaps that makes a difference?]

No. This is a problem with msdosfs(5).

[BostonBSD]

I tried possibly ten times without being able to reproduce anything [on a freshly formatted USB drive]. Then I deleted all of the folders and was able to reproduce it on the first try.

myname@BostonBSD /media> dsbmc-cli -m /dev/da0s1
myname@BostonBSD /media> cd USBDRIVE/
myname@BostonBSD /m/USBDRIVE> ls
myname@BostonBSD /m/USBDRIVE> sudo mkdir test1
myname@BostonBSD /m/USBDRIVE> ls
test1
myname@BostonBSD /m/USBDRIVE> sudo ls
test1
myname@BostonBSD /m/USBDRIVE> cd ..
myname@BostonBSD /media> dsbmc-cli -u -f /media/USBDRIVE/
myname@BostonBSD /media> mount -t msdosfs /dev/da0s1 /mnt/gmounts
myname@BostonBSD /media> cd /mnt/gmounts/
myname@BostonBSD /m/gmounts> ls
ls: test1: No such file or directory
myname@BostonBSD /m/gmounts [1]> icat /dev/da0s1 2 | hd
00000000  55 53 42 44 52 49 56 45  20 20 20 28 00 00 00 00  |USBDRIVE   (....|
00000010  00 00 00 00 00 00 b4 64  30 52 00 00 00 00 00 00  |.......d0R......|
00000020  74 65 73 74 31 20 20 20  20 20 20 10 00 2a ed 68  |test1      ..*.h|
00000030  30 52 30 52 00 00 ed 68  30 52 14 00 00 00 00 00  |0R0R...h0R......|
00000040  e5 4f 4f 54 5f 44 49 52  20 20 20 10 00 b8 af 65  |.OOT_DIR   ....e|
00000050  30 52 30 52 00 00 af 65  30 52 03 00 00 00 00 00  |0R0R...e0R......|

It does look like this entry is different. There is a lowercase short name and no long name. The other entries have a lowercase long name and an uppercase short name.

myname@BostonBSD /m/gmounts> ls
ls: test1: No such file or directory
myname@BostonBSD /m/gmounts [1]> mkdir test2
myname@BostonBSD /m/gmounts> ls
ls: test1: No such file or directory
test2
myname@BostonBSD /m/gmounts [1]> icat /dev/da0s1 2 | hd
00000000  55 53 42 44 52 49 56 45  20 20 20 28 00 00 00 00  |USBDRIVE   (....|
00000010  00 00 00 00 00 00 b4 64  30 52 00 00 00 00 00 00  |.......d0R......|
00000020  74 65 73 74 31 20 20 20  20 20 20 10 00 2a ed 68  |test1      ..*.h|
00000030  30 52 30 52 00 00 ed 68  30 52 14 00 00 00 00 00  |0R0R...h0R......|
00000040  41 74 00 65 00 73 00 74  00 32 00 0f 00 9a 00 00  |At.e.s.t.2......|
00000050  ff ff ff ff ff ff ff ff  ff ff 00 00 ff ff ff ff  |................|
00000060  54 45 53 54 32 20 20 20  20 20 20 10 00 01 17 6b  |TEST2      ....k|
00000070  30 52 30 52 00 00 17 6b  30 52 15 00 00 00 00 00  |0R0R...k0R......|

[test2 was created after using the regular mount command, test1 was created after using the dsbmc-cli mount command]

[BostonBSD]

Whether the directory is created by the superuser or not makes no difference.

myname@BostonBSD /m/gmounts> umount -f /dev/da0s1
myname@BostonBSD /m/gmounts> dsbmc-cli -m /dev/da0s1
myname@BostonBSD /m/gmounts> cd /media/USBDRIVE/
myname@BostonBSD /m/USBDRIVE> ls
test1 test2
myname@BostonBSD /m/USBDRIVE> mkdir test3
myname@BostonBSD /m/USBDRIVE> sudo mkdir test4
myname@BostonBSD /m/USBDRIVE> ls
test1 test2 test3 test4
myname@BostonBSD /m/USBDRIVE> dsbmc-cli -u -f /media/USBDRIVE/
myname@BostonBSD /m/USBDRIVE> mount -t msdosfs /dev/da0s1 /mnt/gmounts
myname@BostonBSD /m/USBDRIVE> cd /mnt/gmounts/
myname@BostonBSD /m/gmounts> ls
ls: test1: No such file or directory
ls: test3: No such file or directory
ls: test4: No such file or directory
test2
myname@BostonBSD /m/gmounts [1]> icat /dev/da0s1 2 | hd
00000000  55 53 42 44 52 49 56 45  20 20 20 28 00 00 00 00  |USBDRIVE   (....|
00000010  00 00 00 00 00 00 b4 64  30 52 00 00 00 00 00 00  |.......d0R......|
00000020  74 65 73 74 31 20 20 20  20 20 20 10 00 2a ed 68  |test1      ..*.h|
00000030  30 52 30 52 00 00 ed 68  30 52 14 00 00 00 00 00  |0R0R...h0R......|
00000040  41 74 00 65 00 73 00 74  00 32 00 0f 00 9a 00 00  |At.e.s.t.2......|
00000050  ff ff ff ff ff ff ff ff  ff ff 00 00 ff ff ff ff  |................|
00000060  54 45 53 54 32 20 20 20  20 20 20 10 00 01 17 6b  |TEST2      ....k|
00000070  30 52 30 52 00 00 17 6b  30 52 15 00 00 00 00 00  |0R0R...k0R......|
00000080  74 65 73 74 33 20 20 20  20 20 20 10 00 c3 c4 6e  |test3      ....n|
00000090  30 52 30 52 00 00 c4 6e  30 52 16 00 00 00 00 00  |0R0R...n0R......|
000000a0  74 65 73 74 34 20 20 20  20 20 20 10 00 9d c8 6e  |test4      ....n|
000000b0  30 52 30 52 00 00 c8 6e  30 52 17 00 00 00 00 00  |0R0R...n0R......|

I could potentially fix this by moving all four directories to my hard drive, after using the dsbmc-cli mount command, then umounting with dsbmc-cli, mounting with a regular mount command and copying all four directories back to the USB drive [this is why I think it has something to do with writing the drive, rather than reading the drive].

[mrclksr]

Thank you for your time and for providing the info.

I found the cause. My first guess was, that the problem was related to the locale conversion, but since the reproduction of the problem seemed so difficult, I thought commenting out or enabling msdosfs_locale = en_US.UTF-8 in /usr/local/etc/dsbmd.conf and restarting dsbmd, I couldn't tell if it makes a difference. But after realizing that the problem could be reproduced reliably after a reboot, I tried unloading the msdosfs_iconv module, which DSBMD loads if not already present, and restarted dsbmd, and the problem occurred again. The problem is caused by the way the kernel iconv library is initialized at the very first mount of a FAT filesystem.
For now, you can comment out msdosfs_locale = en_US.UTF-8 in /usr/local/etc/dsbmd.conf. I've already fixed the code, but I want to make more test before pushing it.

[BostonBSD]

Thank you for your prompt response and patience in addressing this issue. I wouldn't have had the ability to create dsbmd on my own, I lack the knowledge. What you've created changed FreeBSD, in regard to desktop applications, from being an operating system to being a useful operating system. I never would have considered it for this purpose otherwise.

[mrclksr]

Thank you for your prompt response and patience in addressing this issue. I wouldn't have had the ability to create dsbmd on my own, I lack the knowledge. What you've created changed FreeBSD, in regard to desktop applications, from being an operating system to being a useful operating system. I never would have considered it for this purpose otherwise.

Thank you for the nice feedback :)

[BostonBSD]

I just installed dsbmd 1.11.3 and everything appears to be fixed. Thanks again.