- Status Unconfirmed
- Percent Complete
- Task Type Bugs
- Category User Interface
- Assigned To No-one
- Operating System All players
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#13293 - (exFAT) Directories ending with "." (dot) are invisible to file browser
UPDATE2: My SD card is exFAT formatted
Hi!
I realized I was missing some music on my X3ii player and figured out that directories with names that END with a “.” (dot) are invisible to the files browser. My SD card is formatted as exFAT.
Example: “Artist - Album X.”
Tested on both File view settings: “all” & “music” (same result).
Renaming them (removing the dot at the end, on computer) solves the problem.
Dots elsewhere in the name are not a problem, just at the end.
Example of OK dir name: “Artist - X. Album”
It would still be nice if these directories would be shown/accessible since you don’t always remember to rename them beforehand.
Tested on:
xDuoo X3ii
e910f63bba-210520
Thanks!
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
What is your settings for "Show Files" set to?
https://download.rockbox.org/daily/manual/rockbox-xduoox3/rockbox-buildch8.html#x11-1360008.2
I tried "all" and "music". My DIR sorting is by date.
oh and the dot was not the first character in the name.
something like "The Artist - A. B. C. Album"
I realized my description was not completely accurate so I updated the original post.
FAT32 doesn't allow filenames to end with a dot. Might be why Rockbox isn't seeing it.
Are you using a non-FAT32 filesystem?
@amachronic interesting… Indeed my SD card is formatted as exFAT.
Does rockbox only support FAT32/16? I couldn't find anything documented about supported filesystems…
I'll update my original post with the new info.
Thanks.
@impig, the xDuoo X3ii is a hosted port, which means Rockbox runs as an application on the Linux OS "host". So it will support any filesystem that the host OS supports. On native ports (where Rockbox runs as the kernel) then only FAT32/16 has ever been supported.
A filesystem issue is just a wild guess on my part but maybe there is some file name check being wrongly applied.
I'll try to look into it at some point. Thanks for the info.
Thanks for the info and support!
Alright, I created a few folders ending with a dot, put some music in them, on an ext4 filesystem and ran the simulator. Rockbox displays them just fine and plays back okay.
Then I tried formatting an exFAT SD card and creating the same folders on it, using my laptop running Linux 5.10. The results are… interesting.
Note I'm using the 'new' in-kernel exFAT driver, which got added in Linux 5.7. I don't know if the old FUSE driver works the same way.
I don't know which kernel version runs on the xDuoo X3ii, or which exFAT driver it uses, but any which way it looks like you're running afoul of these odd filename rules.
@impig, some further questions:
Thank you.
Thanks for investigating it @amachronic !
1. The original Hiby firmware sees the folder ending with a dot, but returns an error "No File Found" if you try to enter it. Running the "Update the music library" did not index this folder.
2. I copied the files to SD card using Devuan Beowulf which is based on Debian Buster:
Linux 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
In addition to that - My OS / Devuan lets me create folders "A." and "A" side by side on the exFAT formatted SD card, so it does see a difference in those two names.
I tested with the FUSE-based driver on my end and it does differentiate "A." from "A".
The situation gets worse though: re-mounting the filesystem with the in-kernel driver, it can see that those two different directories exist and will show them both in a directory listing, but if you try to access "A." it silently reads "A" instead!
Now if you only have "A." present, the in-kernel driver won't be able to read "A." at all, even though it appears in a directory listing – because it's trying to strip the dots and access a non-existent folder "A".
This is a pretty serious bug IMHO. I can't find anything in the eXFAT spec relating to filenames except the usual banned characters like : * ! < > etc, nothing like stripping dots from the end of filenames.
Based on the behavior it looks like the xDuoo's kernel is using a buggy kernel exFAT driver, rather than the FUSE-based one. I don't think that's something we can fix, unfortunately.
Really interesting indeed… Well it's easy enough to avoid it by ~smarter directory naming (or to know where to look if something is missing in aplaylist) so it's not a big deal if it can't be fixed…
Thanks again for looking into it!