Print

[hargle]

Does anyone know of someone working on a better file system than fatx?
I'm irritated with a 42 character file length, and I think we can do better.  I'd like to get involved with anyone else working on it.  
I'm not afraid of the technical details or doing it all in assembly (my favorite language anyway) but I have no leads as to who to contact to get access to some working bios source to start playing around with.


thanks!

[Textbook]

You might want to talk to Torne.  This guy says he knows filesystems very well, and that he is working on an interesting project right now.  He is trying to get regular FAT (I'm guessing FAT16/FAT32) reading in XBMC.  I'm pretty sure this would solve the problems you have with FATX.  The FAT implementation is very interesting, so take a look at the thread HERE.  I would PM Torne too, just see if you guys can help each other in any way.

[PedrosPad]

QUOTE(hargle @ May 24 2006, 03:40 PM)

Does anyone know of someone working on a better file system than fatx?

Since some XBOX DVD games contained filenames in excess of the FATX 42 char limit, rmenhal implemented a BIOS patch that mounts HDD-based DVD ISO images - thereby upgrading to ISO9660/Joliet file system limits (64 char filenames).  The sources for his 'NKPatcher' are around.

He also expermented with patching the BIOS to use Linux's ext2/3 file system (again, via mounting images), but, IIRC nothing was released.

This post has been edited by PedrosPad: May 25 2006, 12:29 AM

[deadparrot]

Well, the XISO mounting tools were definatley released.

[PedrosPad]

QUOTE(deadparrot @ May 25 2006, 03:17 PM)

Well, the XISO mounting tools were definatley released.

Ah! I guess that's what I ment.  (Momentarily forgot XBOX DVDs weren't ISO9660). (IMG:style_emoticons/default/rolleyes.gif)
Thx for the correction/clarification.  (IMG:style_emoticons/default/happy.gif)

This post has been edited by PedrosPad: May 25 2006, 04:34 PM

[torne]

ext2 would be amusing. Better choice than FAT (IMG:style_emoticons/default/wink.gif)

I want FAT on XBMC for external media compatibility only, you understand...

[programmingace]

Personally, i see a lot of issues with using anything but FATX for the filesystem and still being able to play games... but then again i said the same thing about breaking the LBA-28 barrier too, so feel free to prove me wrong!

the xbox hardware abstraction layer isn't all it's cracked up to be... especally in the later tripple A releases.

[torne]

It's extremely unlikely that commercial software would bypass the Xbox kernel to access filesystems directly, so that shouldn't be a problem. The only reason to open raw drive devices on the Xbox for us, even, is to access sectors outside any partition (to write a partition table compatible with oz_paulb's lba48 patch) or to implement support for other filesystems on external devices (IMG:style_emoticons/default/smile.gif)

[hargle]

ok, so here's my (rather simple) idea.  Apologies to torne who has already seen this.

The xbox-linux page describes a directory entry as such:

CODE

Offset  Size  Description  
     0     1    Size of filename (max. 42)  
     1     1    Attribute as on FAT  
     2     42   Filename in ASCII, padded with 0xff (not zero-terminated)  
     44    4    First cluster  
     48    4    File size in bytes  
     52    2    Modification time  
     54    2    Modification date  
     56    2    Creation time  
     58    2    Creation date  
     60    2    Last access time  
     62    2    Last access date  

My thoughts were for a kernel hack that intercepts this data going to/from the hard drive.
I want to double the amount of data (was 64, now 128 bytes) used for a directory entry.

Use a 2nd block of 64bytes entirely for an additional filename storage, for 106 characters total.

The directory entries would essentially be interleaved on the hard drive:
Block 0=normal xbox entry as described above for 1st file.
Block 1=additional filename storage
Block 2=file 2 normal entry as described above
Block 3=file 2 filename storage
etc.

The downside of this is that in a root directory of any partition, you can now only store 128 files.  Is that really a big deal to anyone?  I have like maybe 15 files in my C: partition and perhaps 6 in E,F.

Subdirectories are not limited to this.  Thus, copying a game with hundreds of files in the root directory of a DVD will not be affected because no one copies a game disk to the root directory of their hard drive.

Games that use a copy protection trick of using longer than 42 character filenames would not be affected by this hack-in fact the game should still work as normal without requiring any hex editing of the xbe.

DVDs themselves are read using a different file system parsing (or so I believe) so this should not interfere with CD/DVD media at all.

Some apps would have to be updated to take advantage of this.  Apps that only reserve 42 bytes for a filename buffer would probably crash if a longer filename was returned.

This patch could also be partition specific.  Keep drives C and E the 42 character method, drive F uses FATx+.  That would keep the MS dashboard and games out of the picture, only homebrewed stuff using the F, G drives could enable this feature.

Anyway, that's the results from my 2 minute pondering into the issue.  There's lots of unkowns (mostly on how to do a kernel patch) and there's certainly more to it than meets the eye I'm sure.

Feel free to shoot some holes in this.

[torne]

Reasonable.

The thing to watch out for will be the Exciting Mystery Bug that results in the filesystem being trashed if you put more than 4096 files in a directory - something in the FATX driver is screwy and it goes horribly wrong if it tries to allocate more blocks than that to a subdirectory. Using two entries per file will pull this down to 2048, unless you discover what causes this braindead behaviour and fix it.

[hargle]

Well then, I'm certainly willing to spend a weekend or two in IDA figuring out how/where directory entries are derived from the kernel, but I'm not sure of what to do once I start changing code.  This is obviously my first kernel hack, and have no idea how to 1) obtain the current kernel I'm using 2) over-write new kernel code into memory for testing.  Any guides out there?  I've not really had the time to research yet.

This EMB bug sounds like it will rear itself to me in a hurry, especially if I drop the limit to 2048 files.
I've probably got that many NES roms installed on my machine already...

[fghjj]

I think for softmod and backwards compatibility it would be best to leave anything in the < 8 Gb area untouched, in standard FATX... in other words only use a new filesystem implementation for F:'s space.

The C/E/X/Y/Z drives are "mounted" the same way as the D (DVDRom) drive, using the kernel function IoCreateSymbolicLink(), right? So there should be some procedure which reads superblocks and detects what FS should be used, FATX or XDVDFS / DVD-video? / audio-cd? (and stores it in some table somewhere in RAM?). Maybe that would be a start?

First you have to look how to actually begin coding... use IDA and modify the xboxkrnl.dll file and use the packing tools to make a fresh BIOS image, or adapt NKpatcher (which source code contains a lot of info btw). I've never really understood how to add code to NKpatcher, it's hard to follow what actually happens with all the VJMP's etc, all the "gaps" which are use to put code in, and you can only debug what actually happens on the Xbox itself.

The ideal xbox FS would have low memory footprint, low fragmentation, allow long and unicode filenames, be fast, non-journaling and have easy limits (16K files per dir / 16 Gb max filesize?) (IMG:style_emoticons/default/biggrin.gif)

[Heet]

Damn this would be one hell of a hack!   (IMG:style_emoticons/default/ohmy.gif)