File Timestamp (DOSBOX Windows XP+)

Here you can discuss the development of patches.

File Timestamp (DOSBOX Windows XP+)

Postby gulikoza » 2009-8-15 @ 13:34

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 :happy:), I just made a separate patch and modified it to apply to current cvs :happy:
You do not have the required permissions to view the files attached to this post.
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: DOS_SetFileDate patch

Postby Dominus » 2014-2-22 @ 13:22

Moved to the patches forum
User avatar
Dominus
DOSBox Moderator
 
Posts: 7273
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: DOS_SetFileDate patch

Postby NewRisingSun » 2014-2-22 @ 13:48

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.
NewRisingSun
Oldbie
 
Posts: 766
Joined: 2005-9-02 @ 02:26

Re: DOS_SetFileDate patch

Postby leileilol » 2014-2-22 @ 16:27

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
User avatar
leileilol
l33t++
 
Posts: 8624
Joined: 2006-12-16 @ 18:03

Re: DOS_SetFileDate patch

Postby Great Hierophant » 2014-2-22 @ 16:38

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.
User avatar
Great Hierophant
l33t
 
Posts: 2323
Joined: 2003-4-27 @ 08:20

Re: DOS_SetFileDate patch

Postby Dominus » 2014-2-22 @ 16:44

I think those should be provided by your compiler.
User avatar
Dominus
DOSBox Moderator
 
Posts: 7273
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: DOS_SetFileDate patch

Postby ripsaw8080 » 2014-2-22 @ 17:12

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.
User avatar
ripsaw8080
DOSBox Author
 
Posts: 4073
Joined: 2006-4-25 @ 23:24

Re: DOS_SetFileDate patch

Postby Great Hierophant » 2014-2-22 @ 19:37

Dominus wrote: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.
User avatar
Great Hierophant
l33t
 
Posts: 2323
Joined: 2003-4-27 @ 08:20

Re: DOS_SetFileDate patch

Postby Great Hierophant » 2014-2-22 @ 19:38

ripsaw8080 wrote: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.
User avatar
Great Hierophant
l33t
 
Posts: 2323
Joined: 2003-4-27 @ 08:20

Re: DOS_SetFileDate patch

Postby ripsaw8080 » 2014-2-22 @ 19:58

XCOPY is an external program, not a shell command, and it works in DOSBox without booting real DOS.
User avatar
ripsaw8080
DOSBox Author
 
Posts: 4073
Joined: 2006-4-25 @ 23:24

Re: DOS_SetFileDate patch

Postby gulikoza » 2014-2-23 @ 10:02

Here's an updated diff against r3858 and added support for COPY command (credits to FeedingDragon).
You do not have the required permissions to view the files attached to this post.
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: DOS_SetFileDate patch

Postby Qbix » 2014-2-24 @ 09:14

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.
Water flows down the stream
How to ask questions the smart way!
User avatar
Qbix
DOSBox Author
 
Posts: 10363
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: DOS_SetFileDate patch

Postby gulikoza » 2014-2-24 @ 09:53

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.
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: DOS_SetFileDate patch

Postby FeedingDragon » 2014-2-24 @ 15:33

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.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 791
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: DOS_SetFileDate patch

Postby NewRisingSun » 2014-4-20 @ 17:56

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.
NewRisingSun
Oldbie
 
Posts: 766
Joined: 2005-9-02 @ 02:26

Re: DOS_SetFileDate patch

Postby gulikoza » 2014-5-09 @ 15:42

10x :)
User avatar
gulikoza
Oldbie
 
Posts: 1698
Joined: 2004-6-25 @ 14:53

Re: DOS_SetFileDate patch

Postby NewRisingSun » 2016-10-02 @ 22:12

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
Oldbie
 
Posts: 766
Joined: 2005-9-02 @ 02:26

Re: DOS_SetFileDate patch

Postby NewRisingSun » 2016-11-24 @ 18:45

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"
You do not have the required permissions to view the files attached to this post.
NewRisingSun
Oldbie
 
Posts: 766
Joined: 2005-9-02 @ 02:26

Re: DOS_SetFileDate patch

Postby Qbix » 2016-11-24 @ 20:36

Wouldn't this "restrict" DOSBox to XP and upwards ?
Water flows down the stream
How to ask questions the smart way!
User avatar
Qbix
DOSBox Author
 
Posts: 10363
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: DOS_SetFileDate patch

Postby NewRisingSun » 2016-11-24 @ 20:37

It would. :)
NewRisingSun
Oldbie
 
Posts: 766
Joined: 2005-9-02 @ 02:26


Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest