DOS ain't dead

RayeR

CZ,
16.03.2011, 00:55

Different behavior of fopen("w") under freedos and msdos? (Developers)

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.

ecm

Düsseldorf, Germany,
16.03.2011, 18:27

@ RayeR

Different behavior of fopen("w") under freedos and msdos?

Post reply

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

RayeR

CZ,
17.03.2011, 14:58

@ ecm

Different behavior of fopen("w") under freedos and msdos?

Post reply

> 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.

ecm

Düsseldorf, Germany,
17.03.2011, 15:40

@ RayeR

Creating files: Lack of error checking in TF kernel

Post reply

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

ecm Düsseldorf, Germany, 08.04.2011, 21:38 @ ecm	Creating files: Lack of error checking in TF kernel Post reply
	There are now patches addressing this in the kernel's repo for the upcoming release 2040.

RayeR

CZ,
10.04.2011, 00:25

@ ecm

Creating files: Lack of error checking in TF kernel

Post reply

> 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.

ecm

Düsseldorf, Germany,
10.04.2011, 00:35

@ RayeR

Creating files: Lack of error checking in TF kernel

Post reply

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

---
l

DOS386

03.05.2011, 09:56

@ ecm

Creating files: Lack of error checking in TF kernel

Post reply

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 ??? :confused:

> (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 ***

ecm

Düsseldorf, Germany,
03.05.2011, 18:03

@ DOS386

Creating files: Lack of error checking in TF kernel

Post reply

> > 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

DOS386

04.05.2011, 11:14

@ ecm

Creating files: Lack of error checking in TF kernel

Post reply

> > 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 ***

ecm Düsseldorf, Germany, 04.05.2011, 14:07 @ DOS386	Terminology Post reply
	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.

RayeR

CZ,
04.05.2011, 18:48

@ DOS386

Creating files: Lack of error checking in TF kernel

Post reply

> 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.

Different behavior of fopen("w") under freedos and msdos? (Developers)

Different behavior of fopen("w") under freedos and msdos?

Different behavior of fopen("w") under freedos and msdos?

Creating files: Lack of error checking in TF kernel

Creating files: Lack of error checking in TF kernel

Creating files: Lack of error checking in TF kernel

Creating files: Lack of error checking in TF kernel

Creating files: Lack of error checking in TF kernel

Creating files: Lack of error checking in TF kernel

Creating files: Lack of error checking in TF kernel

Terminology

Creating files: Lack of error checking in TF kernel