All the more reason to solve it (eventually, not right away). I'm sure our exploit users would love to have CDDAFS compatibility, and for that we need compatibility with EEUG's stuff.Originally Posted by E P
In coding time, yes, it was fast. But that's mainly because we've been planning it for so long. Most theoretical issues were already cleared up, and the basic methods tested, so all I had to do now was to make the practical implementation.Wow that was fast.
In fact all I do is to dump each mcTable struct directly into the attribute file, starting with the one for the containing folder, followed by the ones for each file in it. Subfolders don't need any entries at all, since they get their own attribute files inside.I looked at the config file format and I see that they match up pretty well with parts of the X-port save header.
Good. I really expected it too, as it uses the same methods for attribute and timestamp setting that we tested for the previous version, but we still need tests with the 'tricky' games, of course.The mcPaste works great so far in one of my early tests.
At present I make no attempt whatever to modify the order. I just process the files in the same order they have in the 'files' struct prepared by the 'getDir' function. There are many reasons for this, but the most crucial one is that we can NOT rely on the information in the attribute file to be valid. There may have been other files added since the backup was made and some may even have been removed...The only issue I found was that it doesn't take file order into consideration when copying the files back. I moved the backup to the pc and copied it to the ps2 hdd then restored the backup to mc. The order of the files didn't match the file order in 'PS2_MC_Backup_Attributes.BUP.BIN'. Games probably wouldn't care though.
That makes a strict ordering by the file impossible, so I don't even attempt it. I just use the mcTable data stored in it to update the attributes and timestamps of the matching files/folders that were copied, after making those copies. Any files not covered by the attribute file will get default attribute and current timestamp, and any missing files will simply 'miss' in the calls I make to 'update' them (which is still done for those cases).
I am not worried at all about 'file order', as I doubt very much that any games use this in any way. I'll naturally reconsider this if we get any evidence indicating a real need for it, but I don't think that's going to happen.
I have noticed one mistake I made though, which is that the defaults for files 'not covered' by the attribute file are incorrect, as they fall back to the old defaults instead of the new ones. (0x8417 instead of 0x8497) I will correct this in the next version, though that will double the amount of mcSetFileInfo calls for each mcPaste...
----- snip ----- re: when to make public release
True. I will prepare a new release (v3.42) fixing the error I mentioned above, but otherwise exactly like the beta version.It doesn't really matter to me. Although finishing the mcPaste part and making another release could get more testers in to check it.
----- snip ----- re: sector info for saves
I agree that this is another issue we can 'put to bed', and a good thing too. Inspection of the attribute files produced by mcPaste shows clearly that there is NO such info in the mcTable structs, which (with mcSetFileInfo) are our only real keys to access and control MC attributes.
Now that you have seen it in use, we should perhaps review some of our options for mcPaste again. We could make it the normal copying mode for all cases of copying between an MC and another medium. Doing so has both good points (less confusion for the users is a biggie) and some bad points (like losing the ability to do simple straight copying).
I'm open to suggestions on this, both from you and from users of the new v3.42 which I will release in a new post shortly.
Best regards: dlanor