Windows' WinFile is setting the time in the future

[robert-j]

Describe the bug

Either WinFile or Windows itself is setting the time in the future (about 2 - 5 years. The amount is random).

To Reproduce

• Start WfW 3.11
• Start WinFile, browse the Windows folder
• exit Windows
• enter 'date'

A regression?

Yes. It started to happen a few days ago.

Boot.log

date-bug.log.zip

The file is actually xz-compressed.

[stsp]

A few days ago there were only fdpp updates, so could you please check if it is fdpp-specific?

[andrewbird]

can't create local /var/run/user/0/dosemu2 directory

It's probably unconnected to your problem but that is very strange! What distro/hardware are you running on, or is it WSL?

[robert-j]

@andrewbird: Ubuntu 22.04 LTS virtual machine running in VirtualBox with nested virtualization enabled. Additionally I'm running dosemu with '-s' (sudo) to be able to expose ETH devices to dosemu.

[andrewbird]

I guess that 0 in the path is down to using -s.

[stsp]

Yes, -s should now be fixed. Of course you are aware about slirp and tap, both allowing to avoid -s?

As for windows, the log has things like LFN: using WIN date/time - never seen such. :) Andrew, do you know what these do?

[robert-j]

@stsp: I need a real ethernet interface for my stuff, and the bridge approach has stopped working after updating from 20.4 to 22.4 LTS. Attaching a tap device to a bridge returns EPERM, even as root.

Yes, w/out '-s' the warning goes away. I didn't pay attention and didn't file a bug. Thanks!

[stsp]

man tunctl will hint you about the -u option. And you can use the pre-set tap under dosemu.

[robert-j]

It seems that I'd need some help to debug this w/out fdpp. With MS-DOS 6.22 I get "KERNEL: unsupported DPMI server" from WIN and I have no idea which kind of EMM386 do I have to load (if any?).

[andrewbird]

@stsp something seems to be using int21/714e findfirst and it surprises me that WFW would do this. However I notice that there are no tests to cover these so I've no idea if those calls work with the 64bit time format http://www.ctyme.com/intr/rb-3203.htm.

[robert-j]

It might be 4DOS, which is my default shell. AFAIK it has some LFN support.

Edit: for the records: it's unrelated to 4DOS. With FreeCom same date/time issue.

[stsp]

I installed windows and its barely working. Multiple regressions again. :( Will need to bisect.

[andrewbird]

So I'm wondering now whether the file dates are changing, or just that we are returning bad data that 4DOS displays. Can you try switching to FreeCOM (which also has LFN support, but uses DOS date/time) and see what the timestamps are?

[andrewbird]

@robert-j you anticipated my question, it seems!

[andrewbird]

So run me through the procedure to create a bad timestamp on a file.

[robert-j]

okay, I've manged to configure & run MS-DOS 6.22: the error disappeared, so it's how @stsp predicted: a fdpp issue.

[stsp]

What was the problem? It doesn't work well with ms-dos 6.22 for me too now.

[robert-j]

It's fdpp related.

With MS-DOS 6.22 I can start the same pre-configured Windows, which I usually run under fdpp, then open WinFile and terminate Windows: date/time is still correct, error does not occur.

[stsp]

But what was the problem about a DPMI server?

[robert-j]

Ah, this one: Well, I didn't configure the boot floppy correctly and one of the dosemu drivers was not loaded. This was my bad.

[stsp]

OK, I bisected the windows problem and opened dosemu2/dosemu2#2007 Hope Andrew can deal with the files in a mean time. :)

[andrewbird]

I think the lfn file time is a red herring, I didn't read the full thread until now. The issue appears to be that the system time changes.

[robert-j]

@andrewbird: the file times are correct, probably because they are solely controlled by dosemu.

dir > foo dir foo

shows the current date/time of the system. It's probably only the int 21 getdate function, which is returning bad values.

Edit: not probably. 100% INT21 AH=2A is returning garbage. Edit2: when I'm correcting the date with AH=2B then it remains correct until I start Windows+WinFile again.

[stsp]

Edit2: when I'm correcting the date with AH=2B then it remains correct until I start Windows+WinFile again.

Please see what changes on a native FS are seen from these actions.

[andrewbird]

@stsp I think this might be a packing issue with struct dosdate it seems it's used to set registers! https://github.com/dosemu2/fdpp/blob/926b7c1a64369258e0641cfba1db0242a641965c/kernel/inthndlr.c#L705-L707

[stsp]

struct dosdate
{
  unsigned short year;
  unsigned char monthday, month;
};

I don't see the packing problems here (members are sorted by size), and sizeof() gives 4.

[andrewbird]

Sizes look okay here, but I wondered if the version of clang used would affect things?

[stsp]

No because sizes are sorted properly: "short" goes before smaller "char". You may want to read about alignment and padding rules, they are not essentially trivial. :)

[andrewbird]

You may want to read about alignment and padding rules, they are not essentially trivial. :)

Yes I've been a bit lazy on that front. I have it boiled down to just two options: I don't care about alignment and padding as the struct is internal, so let the compiler do whatever, and I do care because the struct has to be portable, so pack it.

[stsp]

That approach doesn't work if you use -Wpacking option. It will warn on redundant packing, which, on clang-16, is not redundant at all! So what clang-16 does, contradicts itself. Of course, after I reported that, they decided to break also -Wpacking option, instead of fixing things up. Because the "bug" is not following gcc these days, rather than what actually breaks things. :(

[stsp]

There are more problems to that approach. Namely, whatever is packed, is treated by gcc as misaligned! Even when its actually not. So fdpp won't even compile if you pack too much. And unfortunately clang devs almost threaten me with porting that bug from gcc too. :(

[stsp]

So overall you can't pack w/o actually reading about alignment and padding rules. If you do, you will either get a punishment from -Wpacking, or, in case it is gcc - will drown in its bugs, but your code won't work.

[robert-j]

Is there a DPMI layer on top of the real mode INT 21 handler in dosemu? I'm asking because INT 21 2A/2B need a real mode to protected mode translation. Maybe is that place the culprit.

Edit: scratch this, the APIs are solely register-based.

[stsp]

Is there a DPMI layer on top of the real mode INT 21 handler in dosemu?

Yes.

I'm asking because INT 21 2A/2B need a real mode to protected mode translation.

Not above the one mandated by dpmi specs, where the register values are propagated to PM as-is.

[robert-j]

I've tried this:

• start Windows+WinFile
• terminate Windows
• check date: yes, it's wrong
• write to a DOS-native file system, mounted as a floppy
• got this crash:

ERROR: fdpp: abort at /build/fdpp-xbqHwh/fdpp-1.6-1352/fdpp/farptr.hpp:571

This is 100% reproducible.

Observations:

• when I start Windows and don't execute WinFile: no crash.
• when I run any other app in place of WinFile (Office, Delphi, Borland Pascal): no crash.
• EDIT: when I run WinFile and correct the date with INT 21 AH=2A2B after Windows' termination: crash!

Another observation: When I check INT 21 AH=2A in Windows using a Windows protected mode app, then the date is correct before invoking WinFile, wrong during WinFile and wrong after WinFile terminates.

[stsp]

Please attach the log of the crash.

[robert-j]

bug-222.log.xz.zip, actually an xz file.

I've redacted everything containing /drive_c/ for privacy reasons.

[stsp]

Please don't use -s when doing this log. Also you need to install the dbgsym package for fdpp and dosemu2. See this comment on how to: https://github.com/dosemu2/dosemu2/issues/1987#issuecomment-1501099547

You need to grep the resulting log for "No debugging symbols found" and "Could not attach to process." strings. Once they are not there, the log should be good.

[robert-j]

bug-222-2.log.xz.zip, actually an xz file.

It looks like it contains the backtraces you want.

[stsp]

Hmm, it seems fdpp compiler got confused with this statement at fatfs.c:408: j = sp->sftt_count, sftp = sp->sftt_table. Its too difficult for him. :) Could you please try this change:

diff --git a/kernel/fatfs.c b/kernel/fatfs.c
index 79498de..5ddec1e 100644
--- a/kernel/fatfs.c
+++ b/kernel/fatfs.c
@@ -405,7 +405,8 @@ STATIC int merge_file_changes(f_node_ptr fnp, int collect)
   i = 0;
   for (sp = sfthead; sp != (sfttbl FAR *) - 1; sp = sp->sftt_next)
   {
-    for(j = sp->sftt_count, sftp = sp->sftt_table; --j >= 0; sftp++, i++)
+    sftp = sp->sftt_table;
+    for(j = sp->sftt_count; --j >= 0; sftp++, i++)
     {
       if (i != fnp->f_sft_idx && sftp->sft_count != 0
           && fnp->f_dpb == sftp->sft_dcb

That would reduce the complexity and our dumb compiler will probably understand.

[robert-j]

How do I configure dosemu2 to use my custom fdpp from /usr/local?

[stsp]

Just remove fdpp and dosemu2 packages with apt-get, and in an absence of an alternative, dosemu2 will find it in /usr/local.

[robert-j]

It's now crashing in sftp = sp->sftt_table;

[stsp]

Could you please provide a ready to reproduce hd image?

[robert-j]

Not an hd image but a "drive_c" together with the FD image file on which it crashes when I try to write on it after Windows terminates. Is this okay?

[stsp]

If fd image alone is enough (I have win3.1 here too), then that alone.

[robert-j]

The image could be a new, empty one. I've just created a new one and it seems that the bug is not related to my image at all.

My .dosemurc is just this:

$_cpu_vm = "kvm"
$_floppy_a = "dos622.img"
$_attrs_support = (off)

dos622.img is the empty (but formatted) image.

[stsp]

So what needs to be done? Is copying of some file to floppy in winfile is enough?

[robert-j]

I've sent you an e-mail with the subject "FDPP Bug 222".

No, it's much easier:

• start Windows
• start WinFile
• close WinFile
• exit Windows

Then:

cd a:
dir > test

Translation (as it's a German Windows): WinFile is called "Datei-Manager" and can be found in the "Hauptgruppe" ;)

[stsp]

OK, it appeared to have nothing to do with the compilation process. Its a genuine freedos bug.

[robert-j]

@stsp, thank you!

The actual issue (date in the future) of this bug entry isn't fixed, though. You can reproduce the same way as the SFT bug:

• start Windows
• start WinFile
• exit Windows
• type date at the command prompt when back in DOS.

The SFT issue arose while we were arguing about the date bug.