[SOLVED]: Explanation Follows
Posted by EmptyEnvelope2 on .
1. PS3 games are in a so called "UDF Bridge" format, which means that the header contains both the ISO-9660 and UDF file systems.
2. Specifications for the ISO-9660 format require files names without an extension to still have a period at the end (the format of filenames in ISO 9960 is "[file_name].[ext];"). However, the standard is not always followed, and sometimes files with no extension are listed without a period. It seems all PS3 games followed the same standard since they were built with the same tool, and do include a period for file names with no extension.
3. The PS3 defaults to the UDF file system, which does not enforce the use of a period for files without an extension.
4. Typically, extraction and dumping tools default to the ISO-9660 format, and read the filenames from there. Thus, the name of files with no extension are typically written with a period at the end. However, due to Windows not allowing files to end with a period, and due to FAT-32 not allowing file names ending with a dot, the period is still removed automatically (by the tool itself, or by the OS).
5. A tool like makeps3iso does not enforce the use of a period for file names with no extension, so a file ending with a period will be written differently than a file with the same name with with no period at the end.
6. It seems that the PS3 by default interprets file names ending with a period in the ISO-9660 file system section as files with no period at the end. One can see this when accessing (with a hex editor) the header of Minecraft for PS3: The tutorialDiff file ends with a period in the ISO-9660 section (per standard), and does not have one in the UDF file system section.
7. It also seems that the PS3 does not care if a file with no extension in the ISO-9660 section of the header end with no period (probably done to support all Blu-Ray films properly). This means that ISOs created with makeps3iso could have this file with no extension written with or without a period, and it wouldn't matter.
8. The eboot.bin of games call file names with no extension with no period at the end (probably only matters for FAT-32 JB Folders).
2. Specifications for the ISO-9660 format require files names without an extension to still have a period at the end (the format of filenames in ISO 9960 is "[file_name].[ext];"). However, the standard is not always followed, and sometimes files with no extension are listed without a period. It seems all PS3 games followed the same standard since they were built with the same tool, and do include a period for file names with no extension.
3. The PS3 defaults to the UDF file system, which does not enforce the use of a period for files without an extension.
4. Typically, extraction and dumping tools default to the ISO-9660 format, and read the filenames from there. Thus, the name of files with no extension are typically written with a period at the end. However, due to Windows not allowing files to end with a period, and due to FAT-32 not allowing file names ending with a dot, the period is still removed automatically (by the tool itself, or by the OS).
5. A tool like makeps3iso does not enforce the use of a period for file names with no extension, so a file ending with a period will be written differently than a file with the same name with with no period at the end.
6. It seems that the PS3 by default interprets file names ending with a period in the ISO-9660 file system section as files with no period at the end. One can see this when accessing (with a hex editor) the header of Minecraft for PS3: The tutorialDiff file ends with a period in the ISO-9660 section (per standard), and does not have one in the UDF file system section.
7. It also seems that the PS3 does not care if a file with no extension in the ISO-9660 section of the header end with no period (probably done to support all Blu-Ray films properly). This means that ISOs created with makeps3iso could have this file with no extension written with or without a period, and it wouldn't matter.
8. The eboot.bin of games call file names with no extension with no period at the end (probably only matters for FAT-32 JB Folders).
According to the IRD from the vault (the txt log made by Zar's ird tools and Johnny's IRD), there should be a file in /PS3_GAME/USRDIR/Common/res/TitleUpdate/ called "tutorialDiff."
The dot is part of the file name, supposedly. However, the file name in the dump provided in the vault is simply called "tutorialDiff" with no dot at the end, and thus IRD verification fails (at least in ManaGunZ).
Thus, I see 4 possible errors which could be occurring:
a) The file does not have a dot at the end, but the IRD file places one at the end either way (compatibility?). Unlikely since both the IRD from Johnny's Library and the IRD generated by Zar using ManaGunZ contain the ".", and the programs that generated them are most likely different (checksums of the IRD sums do not match each other, but information does).
b) The file does have a dot at the end, but dumping it on a windows machine caused the OS to freak out since files with dots at the end are not permitted, and so it was removed (manually or automatically).
c) The file does not have a dot at the end, but the IRD log dumps places one at the end. Again, unlikely since Zar's IRD tools and whatever tool Johnny used seem to put a dot at the end, despite them being different tools (only recently was Zar's tool made public, so Johnny must have used another tool to see the file names).
d) 7z is messing with the file names while encrypting or decrypting.
Unfortunately, I do not have a Minecraft ISO to check in my PS3 file manager. If someone does, could you please check if the dot is at the end of that file? I assume Vimm that you have (or at least, are able to produce) an encrypted ISO matching Redump. Could you dump it on a none Windows machine to check if there is a dot present in that file name?
Either way, checking for this error will either lead to repairing the IRD included with the ISO, debugging some IRD tools, repairing the dump, or fixing 7z compression. Thus, finding the error is not a worthless endeavor.
The dot is part of the file name, supposedly. However, the file name in the dump provided in the vault is simply called "tutorialDiff" with no dot at the end, and thus IRD verification fails (at least in ManaGunZ).
Thus, I see 4 possible errors which could be occurring:
a) The file does not have a dot at the end, but the IRD file places one at the end either way (compatibility?). Unlikely since both the IRD from Johnny's Library and the IRD generated by Zar using ManaGunZ contain the ".", and the programs that generated them are most likely different (checksums of the IRD sums do not match each other, but information does).
b) The file does have a dot at the end, but dumping it on a windows machine caused the OS to freak out since files with dots at the end are not permitted, and so it was removed (manually or automatically).
c) The file does not have a dot at the end, but the IRD log dumps places one at the end. Again, unlikely since Zar's IRD tools and whatever tool Johnny used seem to put a dot at the end, despite them being different tools (only recently was Zar's tool made public, so Johnny must have used another tool to see the file names).
d) 7z is messing with the file names while encrypting or decrypting.
Unfortunately, I do not have a Minecraft ISO to check in my PS3 file manager. If someone does, could you please check if the dot is at the end of that file? I assume Vimm that you have (or at least, are able to produce) an encrypted ISO matching Redump. Could you dump it on a none Windows machine to check if there is a dot present in that file name?
Either way, checking for this error will either lead to repairing the IRD included with the ISO, debugging some IRD tools, repairing the dump, or fixing 7z compression. Thus, finding the error is not a worthless endeavor.
Replies:
| Re: [SOLVED]: Explanation Follows | EmptyEnvelope2 -- 7/16/2021 11:21 pm UTC |