Hi,
On Thu, Jul 3, 2014 at 8:06 AM, Matej Horvat
<[email protected]> wrote:
> On Thu, 03 Jul 2014 05:16:19 +0200, Rugxulo <[email protected]> wrote:
>
>> Bug compared to what? Do you have experience with other DOSes where it
>> worked correctly (without the Windows GUI)?
>
> Compared to my expectations (:D) and Windows' behavior. I don't know how
> other DOSs behave.
Okay. Just curious why you considered it a "bug".
>> But ... this would probably attract better attention at freedos-kernel.
>
> Good point. I don't subscribe to that list so I didn't even think about it.
I don't either, but it's very low volume.
>> Why is this considered important? What actual programs use these
>> details? Can you present a case for needing them? I'm not opposed at
>> all, just curious.
>
> For informative purposes. I don't do any "automated processing" on them.
But how do you view this data? Certainly there must be some easy way
(without manually viewing raw disk info).
To be honest, there isn't a lot of practical use for timestamps at
all, outside of curiosity. (Makefiles are the only use I can think of,
and even that is weak at best.) There aren't a lot of tools messing
with such file system metadata. Most people don't worry with it very
much (and hence rare bugs crop up in userland stuff if the wrong thing
is set). It's not crucially important, I mean, it's truly trivial.
>> I don't know the details. I assume it was FAT32 only.
>
> It works on FAT16 as well. The creation time is just a part of a FAT
> directory entry.
I'll take your word for it. :-)
>> I vaguely remember some
>> (partial, incomplete) ctime/atime functionality in DOSLFN, but it's
>> not something I would totally rely upon.
>
> I run DOSLFN all the time and I didn't notice them being set. Does it
> require the TZ environment variable to be set?
I don't know about setting / writing. I really only meant reading here.
For instance, in raw FreeDOS, I don't have a working packet driver
(for various reasons). So if I download a file, I use a different
("modern", ugh) OS. Thus, for this machine, that's either Windows 7 or
PuppyLinux. (FreeBSD would work too, but I haven't bothered.)
Anyways, the point is that some files on my FAT32 partition do have
such times set via other OSes.
A quick check of one file (gcc490b.zip) shows three different times.
Here, under FreeDOS, I've successfully tested 1dir, 4dos' dir, and
DJGPP's ls (from /beta/'s fil41b.zip). Thus they successfully show all
three timestamps, which match what Windows 7's dir shows. (BTW, if you
want a text file with this output as proof, I can email it to you.
I've omitted it in this reply for brevity.)
But if DOSLFN is *not* loaded, I only get the same ol' boring
modification time. And while NDN (Necromancer's DOS Navigator) does
support viewing / editing the timestamps, apparently it doesn't read
them correctly, even with DOSLFN. At least, the (other) times are
definitely bogus for the file mentioned above.
So yeah, reading is only half the problem: not all apps will support
it. I'm not really arguing against the usefulness of it (since
obviously modern OSes can't live without it). But you may have a hard
time convincing others. After all, there are presumably more important
tasks to implement (in theory).
>> I don't know if these specific calls can be supported correctly
>> without LFNs enabled. You'd have to ask on freedos-kernel.
>
> I just meant the code that sets a file's creation time when it's created
> (not just its modification time), which is probably just two extra MOV
> instructions. If the associated API functions stay in DOSLFN, that's fine
> with me. And I can live with running a modified kernel too.
You're still not clarifying what programs you'll be using. You expect
every program ever written to transparently support this? In that
case, you can't rely on DOSLFN at all. In fact, most DOS programs
either don't want or don't use both SFNs and LFNs. So you can't 100%
rely on int 21h 71xxh (Win95 LFN) being properly supported, even under
DOSLFN.
Unless maybe the kernel maintainers figure it's acceptable to
implement that one subset of the API internally (without DOSLFN,
obviously). Which isn't the worst idea, but it's still unlikely.
How many ways can you create a file anyways? (3Ch? 6Ch? 716Ch? FCB?)
Does the kernel call a single routine to do each of them? In other
words, you have to make sure every single call is updating the FAT
timestamps.
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
