I try not to talk about Linux, but I have to admit, my past hyperfixation with and experiences using it may have given me plenty of stories to tell, especially now I’m done with Linux. It’s like I’ve got a bunch of cautionary tales. This will probably end up on the desktop Linux problems post too, but IDK. The timeliness of it warrants a new post. 😛
So, I was having a weird issue with FreeFileSync, the GUI app I use for backing up files from my tower to my NAS. A file called "Steps - Tears on the Dancefloor: Crying at the Disco Edition.log" wouldn’t get transferred, and FreeFileSync considers the backup failed as a result. Windows kept thinking the file simply didn’t exist, even though it was pretty much existing. Something wasn’t right though – I couldn’t load it, or even rename it in Windows, either. What was going on?
Well, it has to do with when I used Linux. Yup, Linux was screwing with me despite me not even using it anymore. When I used it, my workflow was basically:
- Rip the CD on my install drive with a log on the rip’s accuracy, using Whipper.
- Populate general tags and move the files, using MusicBrainz Picard.
- Tag genres and submit tag data to MusicBrainz, using MusicBee via WINE.
Sounds alright, but Windows users will already know what went wrong with that file. You see, the colon is something forbidden in NTFS file names, but the Linux install used BTRFS which is fine with those. However, when Picard transferred the files to my 12TB drive, the Paragon NTFS3 filesystem driver on Linux didn’t error out or anything, it basically forced the filename in there even though that was actually forbidden under NTFS standards. That meant when I went to FreeFileSync to back it up, it was trying to grab a file using some Windows API function, and that function got confused at the presence of the colon, probably looking for a file named "Steps - Tears on the Dancefloor" which does not exist.
The fix was simple, go into a Linux distro with the NTFS3 driver (I chose CachyOS since I already have an old USB left over with it) and rename it without the colon. Easy fix, but the use of Linux made it tedious. Guess that settles the dual-boot question.
So, who is to blame here? I don’t blame Whipper, really. It’s not its job to enforce that. Picard should have stopped it as it does have file renaming for Windows filesystem compatibility, but I don’t know if it actually does it for files that aren’t the track’s audio files itself. I’d have to assume not, and I’ll have to go see if I can either implement it or tell MusicBrainz about this oversight. In any case, Linux (or specifically, the NTFS3 driver) should have stopped this right in its tracks and rejected the transfer. Windows does this and Picard throws an error when I do.
So, if you’re ripping CDs on Linux, make sure that log doesn’t have a filename that’ll cause NTFS to shit itself, or maybe use NTFS-3G instead. Oh, and at the same time I also had a bunch of cloned Cover.jpg files, which NTFS is fine with since names are case-sensitive, however SMB doesn’t seem to like this despite Ext4 also being fine with it. I blame MusicBee for that, though.