> I'm not sure if this is a bug, misfeature, lack of testing (re:
> FreeDOS specifically vs. arcane dark corners of MS-DOS), or user
> error.

You don't need to be sure, because I am sure enough what it is.

And what it is, is completely broken file system semantics. Nothing to do  
with "arcane dark corners of MS-DOS". To the contrary, /not implementing/  
proper file system semantics would have been entirely nonsensical if not  
for compatibility with MS-DOS (without its "SHARE"). So FreeDOS reproduced  
this unfortunate architecture (ie file locking implemented in a loadable  
external module that interfaces with the kernel).

The problem is that even with FreeDOS's "SHARE" loaded, file system  
corruption occurs (reproducibly), and in cases that do not fail on MS-DOS  
with MS-DOS's "SHARE" loaded.

> As good as FreeDOS is, obviously we haven't ever had a big
> company kicking the tires. So some minor flaws may persist, but
> overall it seems to works very very well.
> I'd like to hear what Jeremy or Japheth have to say, esp. as I don't
> recall either of them weighing in on this. But others (hi, Tom) seem
> more pessimistic about it "ever being fixed". As much as I like
> FreeDOS, it does seem unlikely that more will get done unless we get
> more volunteers. I'm not too skeptical, but I guess it's more
> realistic (defeatist?) to just accept that FreeDOS will always have a
> few bugs (like any software). We can't have everything, I guess.

If there are enough active kernel developers around, eventually one of  
them should ask me for the small test case program that I created, or  
other technical information required to fix this bug; unless they figured  
it out all on their own already of course. (Naturally such technical  
communication might be more appropriate somewhere else instead of  

But you're right, maybe there aren't.

> But, to be fair, this is not something that most people need, and only
> Marcos seems to have run into this issue. I guess most of us are more
> tame in our usage. At least the code posted on BTTR seems to be user
> error that nobody in their right mind would willingly write:
> fopen("test1","wb") twice in near succession.

Nope, you're wrong.

Besides, that is a typical case that the type of fix I'd propose would  
correctly[*] handle, but the addressed underlying design flaw can cause  
other failures as well (such as when deleting an opened file; according to  
RBIL's Int21.41 description "SHARE" should insure that no file system  
corruption occurs then).

Additionally, the two opens need not necessarily come from the same  
program. After all, there is resident software (besides networking  
servers) which does (write-)access files.

[*] Correct here refers to not causing any file system corruption; in this  
example, data written to that file later would overwrite data written to  
the same file earlier (seeing as no file region locks were put in place  
and the file access modes allowed writes from several handles).


Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Freedos-user mailing list

Reply via email to