File Timestamp (DOSBOX Windows XP+)

[gulikoza]

Due to some requests I ripped the DOS_SetFileDate() patch from ykhwong's sources. This adds the functionality of setting proper timestamp on files with int 21/57 (used by some archivers when extracting files). I haven't found it anywhere, except in ykhwong's full source tree from 2007, so I'm posting the patch here if anybody is interested.

All credits go to ykhwong (assuming he wrote it ), I just made a separate patch and modified it to apply to current cvs

[Dominus]

Moved to the patches forum

[NewRisingSun]

This is greatly appreciated. Thank-you very much. I have been using ykhwong's build for the sole reason of installing games within DosBox, as I cannot stand everything having the same current date. It prevents me from quickly identifying which files contain configuration information written by a SETUP program, and which files are unmodified game resources.

[leileilol]

Agreed, I always hated dates lost.


Linux disagrees though. One time I backed up using that and all my modified dates were reset.


NEVER AGAIN

[Great Hierophant]

Does anyone point me to the utime.h and types.h? That patch adds those includes to local_drive.cpp, but I cannot find them in the DOSBox source, Yhkwong's source or DOSBox-X's source. Without them, the program cannot compile.

[Dominus]

I think those should be provided by your compiler.

[ripsaw8080]

FYI, the patch doesn't address the shell COPY command, which some installers use, and destination files will still get a current stamp. I believe the Daum SVN build uses a COPY.EXE program on the Z: drive to replace the internal command as a workaround. Using an alternate shell like 4DOS is probably another option.

[Great Hierophant]

I think those should be provided by your compiler.

Gotcha, I just had to manually point to the VC include directory and it compiled just fine.

[Great Hierophant]

FYI, the patch doesn't address the shell COPY command, which some installers use, and destination files will still get a current stamp. I believe the Daum SVN build uses a COPY.EXE program on the Z: drive to replace the internal command as a workaround. Using an alternate shell like 4DOS is probably another option.

For hard installs that rely on commands like XCOPY, I typically use real MS-DOS to install them.

[ripsaw8080]

XCOPY is an external program, not a shell command, and it works in DOSBox without booting real DOS.

[gulikoza]

Here's an updated diff against r3858 and added support for COPY command (credits to FeedingDragon).

[Qbix]

I recall from my attempt, that I had a lot issues with getting the date and time to consistenly report to be same inside dosbox, (when external factors changed, like Daylight Saving or changing the timezone).

The reason this is important is the following. Some upgrades (at least one of the apogee games) check the filedates of the installed game. So if you install an upgrade/update later (which is imho totally possible) and the daylight saving changed, then the filedate/time should not be influenced.

Another important part was transferring the data to a different place in the world. (different timezone).
Maybe this patch properly takes care of that. I didn't get a satisfactory version, but maybe I messed something up with the conversions.

I haven't tested this patch yet though. So maybe all of this is a moot point.

[gulikoza]

IMHO that might be an overkill and actually unusable. For the time to be reported consistently, DOSBox would always have to show GMT or something like that and convert from local timezone. But that would mean dosbox would have to be in the future for western timezones and in the past for eastern... Also one would have to consider that some filesystems (NTFS) change timestamps when time changes and others do not...

If the patch does not consider that, even in the worst case (wrong timezone, changing DST...), DOSBox would work the same as now (timestamps wouldn't match). But in all other cases, it would work.

[FeedingDragon]

I have no idea what the change does in that regards. I basically used someone else's code (it's available in the first post.) All I did is patched it in, and added in 2 lines so that the copy command would preserve the code as well. I'd say that 99% (if not more,) of the games used in DOSBox will not be having any future patches, and those installing them now would probably patch them immediately. I don't see much of a problem with it. It is a concern, an should probably stay out of the official builds, but having it available to those that want it, and want to compile it, is a good thing IMHO. For those who want it, and cannot compile it, there are plenty of people (I'm sure,) who would be willing to supply a compiled version. If not, Daum's build does incorporate it in one way or another as well, I'm told. I believe that's where the original patch (in the first post,) came from.

[NewRisingSun]

Something's not right with this code --- DosBox sometimes crashes upon closing a file that had AX=5701 called prior to closing. I'm trying to find out under what circumstances it happens, but when it happens, then always upon closing a file.

Edit: it definitely has something to do with the length of the original (i.e. not within DosBox) path. Moving the offending sub-directory into the root directory makes the bug disappear, purposefully creating paths with more than 120 or so total characters triggers it.

Edit 2: It must have something to do with:

Code: Select all

      char fullname[DOS_PATHLENGTH];
      strcpy(fullname, basedir);
      strcat(fullname, name);

DOS_PATHLENGTH is defined in dos_system.h with a value of 80. Clearly, that is not enough for NTFS file systems. The constant is used many times elsewhere in the code, but there it is only used for virtual (mounted) paths, as far as I can tell, not host paths. It is therefore incorrect to use DOS_PATHLENGTH in this context. Looking at Open(), the correct constant that is always used elsewhere with local paths is CROSS_LEN, not DOS_PATHLENGTH. Replacing DOS_PATHLENGTH with CROSS_LEN indeed fixes the issue, which also occured in SVN Daum because that's where they are taken from.

[gulikoza]

10x

[NewRisingSun]

It turns out that utime under Windows really does not get daylight savings time right. And neither does the Windows function LocalFileTimeToFileTime. This means that after using a utility within DOSBox that uses AX=5701 to set a file to a user-specified timestamp can result in the Windows Explorer displaying dates that are off by one and sometimes two hours compared to what the user specified. The only solution that produces accurate results is to use TzSpecificLocalTimeToSystemTime(), in a "#if defined (WIN32)" block, of course. I'll post a patch later, once I figure out why my own programs using this function compile well in MingW while adding this to DOSBox results in an "undefined reference to TzSpecificLocalTimeToSystemTime" message, even though I'm always linking against the same libkernel32.a which imports that function.

[NewRisingSun]

Attached please find the promised update to gulikoza's patch. For Win32 targets only, it now uses TzSpecificLocalTimeToSystemTime from the Windows API to properly convert file times to the local system time, so that they will match with what is displayed in the Windows Explorer. Again, please refer to this and this page for an explanation of why this is needed. Other platforms should not be affected.

Note that when using MingW, the necessary function TzSpecificLocalTimeToSystemTime will only be known if _WIN32_WINNT has a value of at least 0x0501. This means after applying the attached patch against DOSBox SVN r4000, ./configure must be run (again) with an additional -D parameter, as shown below.

./configure --enable-core-inline LDFLAGS="-static-libgcc -static-libstdc++ -s" LIBS="-lvorbisfile -lvorbis -logg -lFLAC -lFLAC++ -lmt32emu" CPPFLAGS="-D_WIN32_WINNT=0x0501"

[Qbix]

Wouldn't this "restrict" DOSBox to XP and upwards ?

[NewRisingSun]

It would.