I might not have understood your question completely, and I might be wrong about my DOS related memories, but I believe that's how it's supposed to work.
DOS stamped the files with the last written date, so, any move or copy operations re-stamped the files.
Looking at whatever I did today with DosBox (play Dungeon Keeper) shows what, at least to me, is correct behaviour:
I reinstalled Dungeon Keeper after Ripsaw explained some things to me, 9 days ago, so those files are stamped 20/03/2011; the saved game (continue.sav) is 29/03/2011; completely logical, given the fact that I played today. By the way, Windows functions pretty much the same, I copied a 1993 file to another directory and 'lo Creation date gets marked as today, as well as last access, the only remaining one was the last modification date.

Real DOS doesn't do that
some SVN builds have a patch that preserves timestamps

fun fact: this makes shitty abandonware copies a dead giveaway 😀

Real DOS does not have a timestamp for creation, only one for modification. Although the initial timestamp also reflects creation, it will be overwritten with modifications. Some applications like archivers (PKZip, LHA, ARJ, etc.), and DOS itself for commands like COPY, will preserve the modification timestamp of files using a DOS function (INT 21/57) to change a file's timestamp. However, official DOSBox does not implement the function, so the modification timestamp is always the current date/time of the host.

There is some benefit in knowing which files DOSBox has been manipulating, and games/applications are unable to "cover up" the fact by changing the timestamp. For example, if an executable file's timestamp is changed, it could indicate the presence of a virus. I stress that it *could* indicate a virus... some programs update the contents of their own executable files for benign reasons.

FYI, ykhwong's build of DOSBox has a patch to implement changing file timestamps with INT 21/57. However, I don't think the shell's COPY command uses the function, so only software running under the emulation that calls the function will change the timestamps (file managers and archive programs typically do).

I thank you sir, now everything's clear. Yeah, i guess i could take advantage of that little deficiency, but normally i can detect any time/date stamp change myself, so i don't think i'd ever use it to track down infected files. Anyways... thank you very much for explanation. I can still preserve original date/time by managing files from outside DOSBox, in windows or so... in that case they remain intact.

I recall this caused a problem for Duke Nukem 3D. A patch for it identifies files by timestamp. When the patch determines that the file hasn't been there since 1996 it concludes that the file is a different version than needed and stops. I got around it by installing on a Windows 98 system which left the original time intact.

So actually the conclusion should be: DOSBox does not change the date/time of files (back to the ones before the operation on them)

Qbix, right, actually i wanted to add that too, i understood clearly what the issue is. But to make it short i just said that "it changes" whereas it simply does not stamp those back along with the files themselves respectivelly. However, that doesn't make the situation more appealing. To me it's still a "change" and not simply a "lack", if to perceive that process literally as "copying".

Anyways, guys, you ought to supplement your next may-be-upcoming version 0.75 with that INT of yours to make it look a bit more authentic at least in a way the real DOS environment should be. You've already come so far so that there's really a sense of polishing it further a bit getting rid of these little gaps for a mere principle. I'll be looking forward to download your new version with INT fixed. Hope you take it into consideration.

Good luck!

A patch is available here. You can compile it yourself. I doubt it will be added to 0.75.

thanks.

Just for report: DOSBox SVN build's COPY command works with timestamps as well any manager therefrom like NC.

Last time I checked, the COPY command did not preserve timestamps in ykhwong's build. I looked at the latest version, and it hasn't changed. There is no additional code in the COPY command to get the source file's timestamp and set it on the target file. However, ykhwong's build does include an XCOPY.EXE on the Z: drive that is a DOS program (not an internal command like COPY) that calls INT 21/57. As I mentioned before, any file manager, archiver, or other program that uses the DOS function to set the timestamps should work in ykhwong's build.

yeah.... you're right actually, why did i think that it works - no idea. I just checked it myself, managed COPY manually and timestamp changes. That is, doesn't bring the original one back. So yeah... only managers work it out.

ripsaw8080 wrote:

There is no additional code in the COPY command to get the source file's timestamp and set it on the target file.

Haven't you checked FreeDOS website? There are binary and source of COPY command which handles timestamp set. The binary from below link seems to have some issues running in DOSBox so I've replaced it with another one to get it to work.

http://www.ibiblio.org/pub/micro/pc-stuff/fre … files/dos/copy/

actually i need copy to be working via managers such as NC. I won't be needing it much in DOS console itself.

Haven't you checked FreeDOS website?

Er, no, I haven't. I wasn't looking for a workaround, I was pointing out that the timestamps weren't preserved, and why.

I've tried your latest build that includes COPY.EXE on the Z: drive, and I just want to point out that if, for whatever reason, the PATH does not include Z:, trying to do a COPY results in "Illegal command: copy". I'm sure you had to disable the internal COPY command so it would not be used in preference to the external one, but COPY in real DOS is always available, regardless of what's in the PATH.

ripsaw8080 wrote:

Haven't you checked FreeDOS website?

Er, no, I haven't. I wasn't looking for a workaround, I was pointing out that the timestamps weren't preserved, and why.

I've tried your latest build that includes COPY.EXE on the Z: drive, and I just want to point out that if, for whatever reason, the PATH does not include Z:, trying to do a COPY results in "Illegal command: copy". I'm sure you had to disable the internal COPY command so it would not be used in preference to the external one, but COPY in real DOS is always available regardless of what's in the PATH.

Yes, you're right. I will provide a solution in my upcoming build. (Not sure if I can do it though) 😀