Re: msdosfs: Lookup of some existing files fails when mounting with long names

Stefan Esser <[email protected]> Thu, 21 May 2026 13:54:57 +0200
Newsgroups gmane.os.freebsd.devel.hackers
Message-ID <[email protected]>

Am 21.05.26 um 11:31 schrieb Fabian Keil:
> I recently got an USB stick which contains a bunch of mp4 files
> that I want to watch on an ElectroBSD amd64 system currently based
> on stable/15 b718f7d881.
> 
> Unfortunately some of the files can't be looked up when
> mounting the file system with long file names (the default).
> 
> The stick could be copied to a file without problems and the
> issue remains reproducible.
> 
> When the image is mounted with:
> 
>     fk@t520 ~ $sudo mount_msdosfs -m 640 -M 750 -L de_DE.UTF-8 -u youtube -o ro -l /dev/md0p1 /mnt/datentausch/
> 
> some files can't be properly looked up:
> 
>     [youtube@t520 ~]$ ls -lh /mnt/datentausch/*pstei*
>     ls: /mnt/datentausch/Epstein-Akten Deutsche Namen aufgetaucht ?í´.mp4: No such file or directory
>     -rw-r-----  1 youtube fk  413M 2026-04-13 20:47:46 /mnt/datentausch/Epstein Es ist noch widerlicher, als wir glauben.mp4
>     -rw-r-----  1 youtube fk  1.2G 2026-03-07 00:57:00 /mnt/datentausch/Epstein, Ukraine, Covid - Uns müsste schlecht werden.mp4
> 
> When mounting the image with:
> 
>     fk@t520 ~ $sudo mount_msdosfs -m 640 -M 750 -L de_DE.UTF-8 -u youtube -o ro -s /dev/md0p1 /mnt/datentausch/
> 
> the offending file appears and can be opened by vlc so I have a work-around:
> 
>     [youtube@t520 ~]$ ls -lh /mnt/datentausch/*pstei*
>     -rw-r-----  1 youtube fk  1.2G 2026-03-07 00:57:00 /mnt/datentausch/epstei~1.mp4
>     -rw-r-----  1 youtube fk  349M 2026-03-21 09:50:54 /mnt/datentausch/epstei~2.mp4
>     -rw-r-----  1 youtube fk  413M 2026-04-13 20:47:46 /mnt/datentausch/epstei~3.mp4
> 
> There are a couple of other files that are affected but their
> file names are sensitive ...
> 
> When ls complaints about them, their names contain suspicious
> strings like "?í´¥", "?í·", "?í´¥", "?íº" etc.
> 
> Mounting the file system without the -L option results in even
> more lookup failures.
> 
> Reverting 29af6d2e2ec9fe8 didn't make a difference.
> 
> AFAIK, the files were copied to the stick from a GNU/Linux system.
> 
> Fabian

I have fixed a few MSDOSFS issues in recent years and might be able to
debug this issue.

A hex-dump of the directory (search for sectors that contain the DOS
formatted name and include at least 128 bytes preceding it) could help
understand whether this is a bug in FreeBSD or the other system.

Do you know the correct file names on the originating system?

Regards, STefan