> 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
Freedos-user.)
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).
Regards,
Chris
------------------------------------------------------------------------------
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
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
