Bug with Corner cases in renaming impossible file names

[haakonstorm]

(continued from #8)

• I'm writing a small (fix-file-names.sh), that's how I end up with all these edge cases. I even managed to find this (I think) small bug related to as close to the edge you can get an edge case (rename gave up) :

Of course, it's playing dirty serving rename a diet of filenames that only consists of the most impossible-to-handle characters: '$' and '/' and '*' and such... but it's apparently perfectly valid file names in Finder. I work as a consultant working exclusively with networked macOS and iOS boxes around town, and nothing shocks me anymore - if it can be typed, it will end up in a file or folder name sooner or later. And, somewhere along the way, backblaze, rsync, time machine, xar or ditto or even more probably: one of my shell glue scripts, one of those are going to get thrown way off balance by that ' / ' or ' /" ' ...

Don't know if its worth spending the time to band-aid these incredible corner cases, but now at least you are aware of a few perfect 90.000 degree corner cases.

Perhaps you have to go the route of identifying the inode of the file/folder and calling dd(1) [sp?] to zero-out the corresponding parts in the directory?

Anyways.. thanks for a great utility! It's hard at work over here in Oslo, Norway.

//haakon

[ap]

It should certainly do something more graceful than just smack face-first into ENOENT.

I wonder if I should add an option to fall back to something when the target filename is empty. Maybe use the inode number or generate a filename like the Maildir algorithm does, in that case. That way you could be sure you would not have unsanitised filenames left over, ever. Maybe -z should even turn that on by default and allow turning it off only optionally.