Preserving original file/directory timestamps, empty directories, volume label

[tjanas]

I tried extracting a GDI (Napple Tale) and then rebuilding the GDI without making any changes. I noticed some differences in the rebuild GDI. When viewing an original GDI in GD-ROM Explorer, the files have a timestamp of "9/25/2000 8:02:22 AM". When viewing the rebuilt GDI in GD-ROM Explorer, the files have a timestamp that is offset by 9 hours earlier (9/24/2000 11:02:22 PM). Also, in the rebuilt GDI, the directories have their modified timestamp set to the time it was rebuilt (e.g. now) in what appears to be UTC time. I even tried altering the modified timestamp of the directories in the extracted contents, but it not seem to matter.

The original GDI has an empty directory of DPWWW/MODEL. This directory does not get restored when recreating the GDI.

This original GDI has a volume label of "NAPPLE_TALE". The rebuilt GDI has a volume label of DREAMCAST. Is it possible to restore the original volume label automatically via command line?

[Sappharad]

Volume label and other disc metadata can be set in the advanced dialog.

The timestamp and empty directory things sounds like they might be worth looking at.

[Sappharad]

I believe the time shift problem could originate in GD-ROM Explorer. From what I can see by decompiling that app, it's not using the time zone offset in the disc image and just extracting everything as local time:

GDIBuilder writes all timestamps in UTC, since that's just how they're usually handled by most disc image tools including the one I based the image building code on. So each time you extract and rebuild the same image, it's going to move by however many hours from UTC your time zone is.

I'm not sure which is correct. From a standpoint of "this is how the ISO9660 spec says timestamps on disc images should work" GD-ROM Explorer appears to be doing it incorrectly. But if SEGA's original tools also did it incorrectly, then I would need to also ignore the time zone.

I have fixed the support for empty directories locally and also will add the missing timestamps to directories.

Before I do anything else I'll probably contact jc and see if the GD-ROM Explorer behavior is intentional or a bug.

[Sappharad]

Alright, I've answered the outstanding questions myself. I never heard back from japanese_cake, but I confirmed that GD-ROM Explorer's behavior is incorrect. Official Dreamcast GD-ROM timestamps are actually saved with their original time zone offsets intact. A majority of games have their time zones set to UTC+9 which is the Tokyo time zone. But something like Planetweb 3.0 has all of the timestamps set to UTC-8 which is US Pacific time.

Right now, as I said in my previous post, GDIBuilder converts all times to UTC on image generation, but when your operating system converts those back to local time they will be a 1:1 match for the original times. GD-ROM Explorer throws away the time zone info and just treats the original timestamps as if they are your local time zone. So every time you extract a GD-ROM with that tool and re-build it with GDIBuilder, it's going to push the times off by however many hours away from UTC you are.

There's nothing I need to fix regarding the times, since they will be correct according to ISO9660 spec. The only potential improvement I could make is letting you manually set the time zone to write the disc image as. If a tool is properly reading time zone information, you would still see the exact same times no matter what time zone we write the disc as. But once you've extracted a disc's contents, you'll never know what time zone the files came from because both Windows NTFS and macOS convert all times to UTC also. This ensures that no matter what time zone you're in, you'll always see the correct time relative to where you are now.

At the moment, I don't see any benefit to letting you force which time zone your disc timestamps are set to. I'll go ahead and do a new release with the empty folder & folder timestamp stuff fixed, but since jc seems to have disappeared maybe we also need a hacked build of GD-ROM Explorer to fix the time zone problem.

[Sappharad]

It is my intention to release the new version tomorrow. I will close this issue once the release has been posted. I had made some other updates to modernize the code base and they took a little bit longer than I intended.

Edit: I released it, but I'm not closing this issue just yet. More details soon.

[Sappharad]

This is why I haven't closed this issue yet. Since japanese_cake seems to be missing, I'm going to release my own modified build of GD-ROM Explorer that fixes two things:

1. The time zone data on paths is now read from the disc and displayed in your local time zone. Likewise, it's extracted with the correct times for your local time zone.
2. When directories are extracted, the "Last modified" timestamp gets overwritten because it creates the directory and extracts files into it right away. The timestamp for an extracted directory is now set both before and after it's extracted, so the original timestamp is shown in windows explorer as long as you don't edit the content of the folder.

Here I extracted the SA2 demo that came with PSOv2, rebuilt it with GDIBuilder (You can tell because I changed the volume name to TestRebuild), and the timestamps now match perfectly.

Release is coming shortly, I was hoping for today but maybe in a few days.

[Sappharad]

Unofficial GD-ROM Explorer 1.6.3.2 build. I will post about it publicly later in the week once I've tested it more to make sure I didn't introduce any bugs in the process of updating someone else's closed-source application.

Edit: I found another instance of the date that needs to be updated. Also, porting it to macOS because why not.

[Sappharad]

This is now officially released:
https://projects.sappharad.com/tools/gdibuilder.html

The unofficial version of GD-ROM Explorer with time zone fixes can be downloaded via my site at the link above.

[tjanas]

@Sappharad When running gditools.exe --extract-all, it does not seem to be extracting empty directories.

[Sappharad]

@Sappharad When running gditools.exe --extract-all, it does not seem to be extracting empty directories.

I don’t know what that is. I did not write it.

[tjanas]

Apologies, I will try to contact its author.