Hi, On Thu, Jul 3, 2014 at 4:51 PM, Matej Horvat <[email protected]> wrote: > On Thu, 03 Jul 2014 23:09:08 +0200, Rugxulo <[email protected]> wrote: > >> (...snip...) > > You're making this a bigger problem than it is. I'm not suggesting we move > "Windows 95 LFN" functions into the kernel,
Nor me either (though most users would prefer this, but so far it hasn't happened). > just that we modify the kernel > to set the creation times of new files, which is a trivial thing to do > (just two extra assignment statements) and it benefits (if you could call > it that) programs that call "Windows 95 LFN" functions or at least other > operating systems and (I'm pretty sure) it breaks nothing. It might not break anything. I'm not opposed to adding it in that case. But it's not up to me. I'm not a kernel developer. Ask on freedos-kernel. I don't have SVN commit access. But "programs that call Win95 LFN" won't work. They'll do a (potentially buggy) test for LFNs, and when that fails, they'll either fall back to the "classic" MS-DOS 6 APIs or abort with runtime error. There is no way for them to (automatically) know that this one particular subfunction is supported but others aren't. They usually assume all or nothing. (And most DOS compilers and libraries [except DJGPP etc.] always assume that LFNs are *not* available.) > Although, taking another look at it, the comment above the init_direntry > function does say "creation/access stamps 0 as per MS-DOS 7.10", There was no LFN support in plain MS-DOS 7 (by default). Only "Windows" GUI supported it. (Probably a bad decision, but it was theirs to make.) > so apparently not setting those times was a deliberate decision. In that > case, fine, I understand that my suggestion is going to be rejected Don't assume the worst. Ask on freedos-kernel. I mean, don't get your hopes up, but it's not a bad suggestion. And just because MS-DOS didn't support something isn't a valid reason. Who cares what they lacked? FreeDOS has never tried to be "bug-for-bug compatible". If it's a bug or omission, it should be fixed. FreeDOS has always been open to improvements. Your only main problem is finding someone with commit access and proving your case (why it's useful, not harmful, easy to implement). Jeremy Davis (on his private Git repo) did make a small kernel bugfix for SysLinux recently, so it's not like there is literally no hope! >> In other words, you have to make sure every single call is updating the >> FAT >> timestamps. > > For the creation time, it seems there is only one place to do it. For the > last access time, I'm sure we agree it's useless. :) Not useless, just slow. AFAIK, that's the rationale for avoiding that one. It's no more "useless" than creation time. (Admittedly kinda niche, but apparently somebody cares, or no file systems would support it.) > Even Windows doesn't update it by default since Vista, though admittedly only > for NTFS: > > http://blogs.technet.com/b/filecab/archive/2006/11/07/disabling-last-access-time-in-windows-vista-to-improve-ntfs-performance.aspx Vista (on up) also won't boot up the OS itself from FAT at all anymore. But I don't think we have the luxury to mimic that decision! ------------------------------------------------------------------------------ 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
