Print

[dus]

I belive the following patch would have the same effect as the patch above. It basically changes the end of file (EOF) constant to 0xffff (FAT16) alt. 0xffffffff (FAT32), used when creating files. The end of cluster (EOC) is left untouched because this is used when finding the end of the cluster list, which according to the normal FAT specification is anything between 0xfffffffe and 0xffffffff (32-bit).

(Disclaimer: I have NOT tested this. You might get lucky and it works.)

CODE

--- kernel/include/linux/fatx_fs.h.~1.6.~       2005-12-18 00:36:24.000000000 +0100
+++ kernel/include/linux/fatx_fs.h      2007-09-15 14:31:45.000000000 +0200
@@ -65,8 +65,8 @@
 
 #define EOC_FAT16 0xFFF8       // end of chain marker
 #define EOC_FAT32 0xFFFFFFF8   // end of chain marker
-#define EOF_FAT16 0xFFF8       // end of file marker
-#define EOF_FAT32 0xFFFFFFF8   // end of file marker
+#define EOF_FAT16 0xFFFF       // end of file marker
+#define EOF_FAT32 0xFFFFFFFF   // end of file marker
 #define EOF_FAT(s) (FATX_SB(s)->fat_bits == 32 ? EOF_FAT32 : EOF_FAT16)
 
 #define FATX_VALID_MODE (S_IFREG | S_IFDIR | S_IRWXU | S_IRWXG | S_IRWXO)

[dus]

Above I meant that EOC stands for end of chain.

In addition to this, according to the FAT specification, you should not consider the top 4 bits in the cluster number. In the xbox-linux file kernel/fs/fatx/cache.c, there is a next &= 0xffffffff, which I believe should be next &= 0x0fffffff.

This is quite amusingly stated in the linux-2.4.35.2 kernel (linux-2.4.35.2/fs/fat/cache.c):

CODE

[...]
                next = CF_LE_L(((__u32 *) bh->b_data)[(first &
                    (sb->s_blocksize - 1)) >> 2]);
              /* Fscking Microsoft marketing department. Their "32" is 28. */
                next &= 0xfffffff;
[...]
 

Also, in the xbox-linux kernel kernel/fs/fatx/cache.c file the use of EOC_FAT32 and EOC_FAT16 misses the possibility of a bad cluster 0x?ffffff7 alt. 0xfff7. (Compare with the fat file of a linux-2.4.35.2 kernel.)

This just in case someone wants to do something about it.

[ldotsfan]

QUOTE(BitBasher @ Sep 15 2007, 04:30 AM)

It would be nice to update xboxhdm, but as far as I know, ldots never released the source code for it, and he hasn't been active on XS since mid 2005.

It's possible to fix all the patch files on xbox-linux, but that would still require everyone to grab the updated patches and rebuild their respective kernels.  This may only be a problem with 2.4.xx kernels, as the code for the 2.6.xx kernels is different - I'm not 100% sure.

I just checked one box running Xebian 1.1.4 and it has the problem, and another box that was created using xboxhdm also has the problem.  I'm not sure if Gentoox has this problem or not.

Bit.

I've used Xebian 1.1.4 as my development environment (running on vmware) and used the CVS copy of the 2.4.32 kernel from xbox-linux to fix this FATX bug. So xboxhdm can be updated and I've done it. My testing consists of running the version on vmware. I've dumped some files on it from my desktop's c drive and doing some file operations but of course this is not really a thorough test.

Actually the bulk of xboxhdm's meat is a list of shell scripts written by ldots and are self-documentary. Now the issue is how to test the new version of xboxhdm. Just three files in the isolinux folder need to be replaced. Any volunteers to test? Alternatively can somebody point out how I can cross-check the files created by MS kernel vs xboxhdm ?

Also is it useful to release a version of xboxhdm that can access shared folders on a remote windows machine and USB storage devices and add some scripts to ease access to these folders from Midnight Commander  (like what ldots did for the xbrowser script)?

[kingroach]

I can put on some time if needed.. booting from usb shouldnt be a problem.. you just need to update the scrips a bit.

[ldotsfan]

Thanks the link has been sent to you.

[kingroach]

I got it.. I will look into it asap..

[ldotsfan]

I already used the kernel to rebuild/upgrade one xbox HD and so far it's not complaining yet (no obvious file corruption). Another issue is it seems a very common PC hardware configuration comes with only 1 IDE port and the rest are all SATA. I've tested this kernel with xboxhdm on vmware with only 1 IDE enabled and apart from the obvious function (cloning), the rest of the functions don't seem to be tied to secondary master for CD.
So it might be a good idea to upgrade xboxhdm to support CD on primary slave for all functions except cloning so that modern PCs are properly supported.

[ldotsfan]

@kingroach : Did you had the chance to do any testing on the FATX bugfix?

The USB flashdrive booting is working. Hotswapping from USB/IDE adapter should work too. Now in this test version, there's no need to reboot between building the xbox hdd (option 1,2) and locking it(option 3). No restrictions on the physical IDE connection - now it can be primary/secondary master/slave. And cloning should be faster since it's a newer kernel - in theory. I hope to include 32k/64k cluster size support as well. But I'm still working on the last feature.

[ldotsfan]

QUOTE(obcd @ Apr 22 2008, 04:35 PM)

I don't want to slow down your enthousiasm, but it was my opinion that a cdrom connected as primary slave could no longer be accessed once the harddisk on the primary master was locked. I could be wrong about this. You surely won't be able to do a hotswap that way. Booting from an usb stick might be the solution here. If you managed to use the lock tools in the same Kernel that has USB support, that shouldn't be a very big problem. Altough I wonder if they don't unmount the harddisk before they feed it the low level locking / unlocking commands. I suppose linux can do this without a reboot.

  when xboxhdm was built, they didn't have a technology that has since matured - virtualization. I used qemu in my solution. Host is a 2.6 kernel with USB support , guest hosted by qemu is the original xboxhdm kernel (2.4) for FATX support. the cdrom is a virtual one running from the iso and before locking takes place, you would have shutdown the guest.

QUOTE(obcd @ Apr 22 2008, 04:35 PM)

How can you see this xboxhdm disk corruption in the first place? (I know, it's not really a corruption.)
So many people used xboxhdm to create their xbox harddisk. I don't hear much complaining.

rmenhal is the one who spotted the bug and provided the original fix. Pls search for the post for details.

QUOTE(obcd @ Apr 22 2008, 04:35 PM)

There exist a program called winhex that can analyse a harddisk on a very lowlevel way. I don't know how much fatx differs from fat32, but it might be a way to check the fat tables and see what was used to indicate the last cluster of a file. (Which is what differs if I read well.)

The equivalent in linux is the dd command. Can you suggest a specific test scenario that I could try out?

QUOTE(obcd @ Apr 22 2008, 04:35 PM)

The primary purpose of xboxhdm is creating the C and E partition needed to make the harddisk usable in a xbox. The larger F and G partitions can be created afterwards. If a bigger cluster size is needed, xbpartionner can do the job, so I don't think you should put a lot of efford into the 32 and 64 bit Cluster size.

Actually it's basically done, I've posted the details in the linux forum, just need others to verify my work.

QUOTE(obcd @ Apr 22 2008, 04:35 PM)

An upcoming problem is indeed the fact that most pc's only have one ide port left, and usually don't have a floppy drive anymore. An upgraded xboxhdm that solves those issues would help a lot of people.

Yes, that's the main motivation.