A few weeks ago someone contacted me regarding my OMFS filesystem driver for the Rio Karma. His interest is in getting it working for ReplayTV to do who knows what. This is coming a bit full circle, as I discovered long ago that the RK and RTV use the same proprietary filesystem, and indeed the ReplayTV hackers of yore had documented nearly everything there is to know about the FS, without which I would’ve been lost writing the Linux kernel driver in the first place. Of course, there are some differences in the way the two devices do their thing.
I don’t own an RTV, but I like a challenge so I asked him to send me a dump of the first gig of the disk. One look and it is the crack-headedest thing I’ve seen in some time: somewhere along the way, their block layer must’ve moved from a big-endian to little-endian platform, without changing the code. OMFS is a 64-bit FS but the RTV block layer apparently works on 32 bits, so for example the 64-bit value 0x8877665544332211 gets written to disk as 0x5566778811223344. And it’s not just the metadata: *everything* is swapped. Filenames look like “tusCzimo..re” instead of “Customizer”. File data blocks are all swapped. Very odd.
Well, for a time I’ve been wanting to experiment with OMFS written in FUSE, so I took my userspace routines from omfsprogs and in the space of an hour or two had a read-only FUSE-based OMFS that did the necessary byte swapping to work with Replay’s file system.
The payoff is the text file that RTV developers apparently used in their version control process. I give you: ReplayTV “Token Haiku” (after the jump).
Continue reading “Hacking ReplayTV”