DOS ain't dead

Hi,
I tested my program (compiled in djgpp) on write-protected floppy and found there's very different behavior what happen if run under msdos and freedos 2038.
Under msdos I got null pointer as expected according to ansi c spec. If I then tried to write to NULL by fwrite() program crashed.
Under freedos it opened something (NUL device?) and fopen returned a valid pointer. fwrite() didn't crashed, fclose() didn't return error. But of course file was not created. I think this is a bad idea because application may confuse user with notification that file was successfully created blabla and it isn't. I would suggest to return null as ususal...

---
DOS gives me freedom to unlimited HW access.

fopen, fwrite and fclose are not functions provided by FreeDOS itself directly - these functions are in the compiler's libraries. They use DOS functions. I'm just saying that a test case in assembly would probably be more useful to the FreeDOS developers. They may need to know the compiler you use anyway, because this error could possibly occur on specific compilers only.

---
l

> fopen, fwrite and fclose are not functions provided by FreeDOS itself
> directly - these functions are in the compiler's libraries.

Yes. I asked DJGPP group and got some reply pointing the involved DOS calls:

What happens is that fwrite copies data to a buffer
until it is full, then calls _flsbuf (see flsbuf.c in djlsr203.zip),
which in turn calls _write (see _write.c) which invokes Int 21h with
the AH register set to 40h, the DOS Write To File Or Device function.

As for fopen, the exact sequence of system calls depends on the flags
you passed to it. I think it eventually calls Int 21h AH=3Ch (Create
File), but I cannot tell for sure without seeing your code.

---
DOS gives me freedom to unlimited HW access.

Oh, so are you creating/truncating a file (by opening it) in this case? Yes, that shouldn't work if the directory is write-protected. (As an aside, DJGPP appears to use the obsolete function 3Ch to open the file if it is to be created - this means that it opens files in compatibility mode, because the caller cannot specify the open/access mode with that function. But that doesn't matter here.)

In The FreeDOS Kernel source I have around (probably 2038 or 2039), functions to create local files call down in this order: (Interrupt 21h handler) -> DosOpen -> DosOpenSft -> dos_open -> dir_write_update (by dir_write macro). In dos_open, a boolean return value of false that can be indicated by dir_write_update would cause an "Access denied" DOS error that would presumably be returned all the way back to the interrupt 21h caller and would release the tables/handles allocated to the file at this point. However, dir_write_update (in fatdir.c) apparently only returns false if it failed to allocate a buffer. This is even indicated by a comment above a call intended to flush buffers for the affected file system, describing that call as "Clear buffers after directory write or DOS close" and pointing out "hazard: no error checking!".

I suspect that writing the changed buffers individually and checking for errors from the device driver at that point would fix your test case. However, there might exist other such cases where The FreeDOS Kernel fails to verify that buffers it intends to flush were written correctly. Function 40h handling ought to be checked.

---
l

There are now patches addressing this in the kernel's repo for the upcoming release 2040.

> There are now patches addressing this in the kernel's repo for the upcoming
> release 2040.

Well when it will be out?

---
DOS gives me freedom to unlimited HW access.

Refer to this thread on Freedos-kernel. Accordingly, release 2040 will go official during this month still.

---
l

RayeR wrote:

> I tested my program (compiled in djgpp) on write-protected floppy and found
> there's very different behavior what happen if run under msdos and freedos 2038

Test code ?

> Oh, so are you creating/truncating a file (by opening it) in this case?
> Yes, that shouldn't work if the directory is write-protected

So what was write-protected now ???

> (As an aside DJGPP appears to use the obsolete function 3Ch to open

How to find out ???

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > Oh, so are you creating/truncating a file (by opening it) in this case?
> > Yes, that shouldn't work if the directory is write-protected
>
> So what was write-protected now?

If the disk device is write-protected, then the file system is write-protected.
If the file system is write-protected, then the directories are write-protected.
Was this conclusion so hard?

> > As an aside DJGPP appears to use the obsolete function 3Ch to open the file
>
> Would you like to use my program UI21DEB to verify this?

No thanks. I only read that DJGPP uses function 3Ch in the DJGPP list quotation RayeR provided. But it's not worth looking into right now. This is just trivia not really related to this topic.

---
l

> > So what was write-protected now?
> If the disk device is write-protected, then the file system
> is write-protected.
> If the file system is write-protected, then the directories
> are write-protected.
> Was this conclusion so hard?

NO. FAT directory entries do carry an R attribute bit, having no effect, they are still writable even if the bit is set. But some apps do peek this bit and refuse to write then

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Obviously I would have said "read-only" if I meant that this attribute bit was to be set

More seriously, it was implied that I wasn't talking about that attribute bit. First, one could assume that the test was writing files to a root directory, and the root directory doesn't have attributes. Second, the conclusion really wasn't that hard.

> Test code ?

Nothing special, simply three lines calling
f=fopen(...)
printf(f)
fwrite(f)
I think everybody can try it :)

---
DOS gives me freedom to unlimited HW access.