macOS shell - arrange images by inode numbers

[organicCPU]

Overview:
How can I edit the inode number (ls -i /path/to/file) of certain files after file creation on a FAT-32 filesystem?

Why I'd like to do this:
During the holiday season I encountered a problem with jpg images on USB flash drives showing up in some weird order on a Philips TV. After all, it turned out, that the TV just recognises the file serial number for the sequence to play. If a camera or its SD card is attached this ensures chronological order, what makes sense to me, but (re)arranging exported images from a Mac is a hassle, if trying to insert some images in between some already saved files. First I couldn't believe, that neither file name nor file modification, access, creation date nor some EXIF info is selectable for sorting the images on the Philips TV.

Ways I could go:
My first thought was about writing a Bash Script that does (re)formatting the USB flash drive to demanded FAT-32 filesystem (to wipe the file catalog) and then does copying one file after another to get the order I desire, but editing the inode number and/or file catalog seems to be a much faster and smarter solution.

Questions:
- Is the inode number the commonly used only criteria on (modern) TVs for sorting image files to display or is that a special Philips thing?
- I read about debugfs for e.g. ext4 filesystems, but I wonder if there is an equivalent for FAT-32 filesystem?
- I've been using SetFile for file modifications so far, but it doesn't look to be capable manipulating the inode number. Is there a (built-in) tool on macOS to edit inode numbers?
- If there is no existing tool for macOS, which functions in C, Objective C or Swift should I take a look at?

Any suggestion that includes the use of separate jpg files and is pointing to the right direction to get control of the allocation of inode numbers is welcome!

 

[Krevnik]

Editing the inode numbers would require raw filesystem-level access, which I really don't recommend pursuing. That way lies madness, as you are trying to edit the filesystem itself, and things like the inode numbers aren't really meant to be user-exposed in the first place, and haven't for a very long time. The only thing that should cause a new number to be generated is if a new file is created.

If you ask me, the Philips isn't trying to sort at all, it's just asking what files are on disk and displaying them in the order found. In other words: "unsorted". This just happens to be the "order" that the internal filesystem is using when listing files in a directory: inode numbers. Inode numbers shouldn't be used as any sort of sorting key, IMO.

Finding a way to edit the inode number is a recipe for eventual filesystem corruption. These numbers are really unique identifiers/keys for files, they aren't meant to be changed once the file is created, which is why you aren't having any luck finding ways to change them. Other parts of the filesystem refer to them, and if they get out of sync, you will wind up with some form of corruption. It's honestly easier to recopy the files in order you want them to appear in this case.

And yes, the fact that this TV doesn't actually do any sorting is pretty dumb.

EDIT: Even worse, FAT apparently doesn't even use file IDs on disk, so the inode numbers you see aren't actually present anywhere but memory. There literally isn't anything to edit in that case, even if you could.

 

[organicCPU]

I agree. Modifying file systems for sure is a bad idea in general, but in this case it's just too inviting. Even if it would break when things go wrong it's a replaceable USB flash drive.

That I get a new inode number while writing a new file is true and probably the best method to face the problem. However, I realised that deleting files on the USB drive and writing them again back to there, doesn't change the order of file appearance on the TV. I'll investigate further, if the same former inode number is assigned or if such files get a different inode number, what would make my theory obsolete. By reformatting and copying files again I could get the desired order. If I drag a whole folder of files I get a random order of files, dragging files that are selected itself occur in the correct order like sorted in Finder, but I'm not sure if I'd always get results that are FIFO. I'm also not sure if the inode number or the according directory catalog entry for FAT-32 is getting assigned at the beginning of writing a file or at the end and finally under what circumstances files are written in parallel or serial. Things I'd need to find out, before a script would work.

Unsorted is exactly what the Philips TV image order describes best. If it's the inode number or some equivalent that macOS knows to hide and I can't explore, I don't know by now. What I know is, that there are inode numbers shown on the USB flash drive if I execute 'ls -alOi'. I did remove all the macOS related metafiles starting with a dot by 'rm .*' and these were no more present nor extended attributes. I don't think that the inode numbers are coming from memory, but it might be that they are just there because of the Mac writing to the USB and you're right that they might get ignored by the TV or Windows system, too. AFAIK, on FAT-32 in the File Allocation Table's directory entry there is similar information stored as in the inode on Mac, etc. The inode number is just one single part of the so called inode, that indeed isn't present on FAT. AFAIK the major difference is, that if I open a file on UNIXes, the file is accessed through an inode number and on Windows that's handled somehow different. What kind of OS the Philips has is just a speculation, but as it only reads NTFS and FAT, it's quite obvious that it must be some kind of Windows based system.

As an incidental remark, if I delete the whole EXIF Tag with ImageOptim, the jpeg gets unreadable by the TV. So far I've been changing everything I could with SetFile and exiftool and finally discovered that the succession of images on the TV goes conform with the inode number. That's why I thought I could try my luck changing the inode number in the hope the Philips TV would honour it. If I only knew how to do this on FAT-32, like with the Virtual File System debugfs that is available for Mac, but only does its job for ext2, ext3 and ext4 filesystems. If it would have nothing to do with the inode number at all, but more or less only with the order of bytes 0x0C to 0x15 of the FAT-32 directory entry, I'm really curious enough to know a way to get access to that raw filesystem-level with a Mac. And yes, dumb TV that even isn't mine. Thank you for your reply.

 

[Krevnik]

Yeah, the inode number you see on Unix is generated by reading the catalog. And so the only way to adjust the ordering is to read, alter, and write the catalog back out. To do that, you can’t have the Filesystem mounted, and would need to read the drive raw using some code that understands the FAT catalog. I don’t know if existing libraries exist that allow you to rewrite the catalog like that already, or if you’d need to write chunks of it from scratch. This sort of manipulation is not really done, except by the Filesystem itself, usually.

 

[organicCPU]

Incredible! Thank you again @Krevnik! What you wrote pointed the way ahead for me. The plan so far: 1.) Make a block-level copy to disk image of the unmounted USB flash drive (/dev/rdisk) with dd or ddrescue, 2.) Examine the unmounted raw device or the disk image with some tool like wxHexEditor to get a better understanding of what is really stored and how data is looking like, 3.) Find and replace yet unknown entries manually and write all back to USB.

Once I know what to do radare2 seems to be the right tool capable of getting step 2 and 3 done involved by a shell script. One of the major problem I expect I'll get is that AFAIK the FAT filesystem is storing in addition to one or more copies of the File Allocation Table even more info about each data region alongside every single directory inside a Directory Table mixed up with the actual data. Then, if the TV is really just showing plain unsorted data like stored on disk I'll probably have to move and exchange whole sections. Seems like getting much GREPing work...

Additionally to the idea of manipulating the file system, I'll also follow the different approach of learning the basics of controlling sequential file writing.