Suggestion For Hd Backup Apps, 42+ char filename Options

[Xeero]

This is a very obvious suggestion, and I'm not sure how hard this would be to implement, so give me a kick in the ass if it's a hefty task...

It seems to me that it would be fairly easy to have an app (like DVD2Xbox...wink-wink) copy all files to the HD normally, and when it runs across a 42+ char filename it could rename it to be within the FATX filename length restriction, then log the original and new filenames to a temporary file on the HDD (on X, Y, or Z). Once the backup is complete, it could then search the default.xbe for all references to the old filename and replace it with the new filename (remaining bytes replaced with null chars). It would have to make a few passes over the XBE, granted, but the XBE is generally small so it would not take that long.

This would effectively make the app capable of backing up any game to the hard drive, which is a nice disctinction.

[WiSo]

I had the same idea and briefly looked into it but I found no references to the used files in my testgame.

[Xeero]

What was the testgame out of curiosity? I checked the default.xbe of Enter the Matrix and found the filenames.

[WiSo]

cell damage or similar. I know it contains no long filenames but I thought to find at least something
Seems to be worth a try. I'll try to get a game with long names for investigation. Could you
name some ?

This post has been edited by WiSo: Jul 25 2003, 04:33 PM

[WiSo]

I would appreciate if you could some prework
find two games which don't run from hdd. Patch them where neccessary and run them again.
When they run send me the names of the games.

Thanks.

[shaftastic]

Verry good idea! Would be a kick ass app if it was made.

[WiSo]

@Xeero: any progress ?

[Xeero]

I hadn't seen your last post, I apologize. Let me dig up ETM when I get home.

[BenJeremy]

I'm looking at doing an "autopatch" for FATX names with MXM's game ripper (when I implement it), but there are several other issues to deal with:

1) The names may appear in other files, data files, for example.

2) The organization of data may mean that you simply cannot PATCH the name to shorten it... i.e. a table of strings might be NULL delimited and parsed through. A patched filename might short-circuit the program's transversal through this list when it hits the patched filename that's shortened by tacking in a NULL character, and take the tail end of the name as the "next" filename.

Nonetheless, I am working on it. If I can find an elegant solution, it will be an optional part of the game ripper.

As further insurance for correct game ripping, I am considering implementing pre-defined profiles for patching game discs to handle copying to the HD. I'm sure Koldfuzion or others might be willing to host these files (no copyrighted code, only info on what to rename, where/how to patch).

The system could be Public Domain for other dashboards and game rippers to use.

[Xeero]

QUOTE (BenJeremy @ Jul 29 2003, 12:38 PM)

As further insurance for correct game ripping, I am considering implementing pre-defined profiles for patching game discs to handle copying to the HD. I'm sure Koldfuzion or others might be willing to host these files (no copyrighted code, only info on what to rename, where/how to patch). The system could be Public Domain for other dashboards and game rippers to use.

I really like this idea. It could be a very simple instruction file...as basic as an INI file...maybe to the extent of.

CODE

[PATCH1] n1=default.xbe [PATCH2] n1=default.xbe n2=wsb.xbe [RENAME] old1=48charfilename.dat new1=48char~1.dat old2=57charfilename.dat new2=57char~1.dat

Obviously an INI isn't elegant, but my point was to demonstrate just how simple a profile could be. I'd think there would have to be additional instructions on how to modify the XBE other than media patches 1 and 2 (i.e., to accomodate the renaming of long filenames), but that's not something I'm going into detail about here.

This post has been edited by Xeero: Jul 29 2003, 03:49 PM

[BenJeremy]

Forget INI files. Too cumbersome form the programmer's point of view.

XML is more suitable anyway. Patch bytes could be described in packets...

<GAME XBEID="0x45670001" XBETITLE="Some Game">
<RenameTable>
<File>
<Old>somelongassnamebiggerthan42characterslongdammit.dat</Old>
<New>nicename.dat</New>
<File>
<Directory>
<Old>somesuperdupercaliphraginisticexpialidociousname</Old>
</New>shortandsweet</New>
</Directory>
</RenameTable>
<NamePatchTargets>
<ASCII>
<Target>default.xbe</Target>
<Occurance>all</Occurance>
<Type>Unique</Type>
</ASCII>
<Unicode>
<Target>default.xbe</Target>
<Occurance>all</Occurance>
<Type>Table</Type>
</Unicode>
</NamePatchTargets>
<BinaryPatchTargets>
<File Target="default.xbe">
<SearchReplace>
<Old>0x45 0x90 0xae 0x55</Old>
<New>0x45 0x90 0xee 0x55</New>
</SearchReplace>
<Cut>
<Location>0x64783</Location>
<Size>0x422</Size>
</Cut>
<Insert>
<Location>0x42793</Location>
<Data>0x33 0x65 0x67 0x86 0x96</Data>
</Insert>
</File>
</BinaryPatchTargets>
</GAME>


and so forth... the files might be somewhat large, but easily readable by any app with a decent XML parser (MXM has an open sourced XML parser)

[Xeero]

Haha, I'm XML-stupid, so like I said I was just using the INI as a display of how elementary a profile could be.

Also, I'm assuming you had all kinds of tabs that made the XML look much prettier.