Thanks. Here's some comments if you care to read them. Not all of them are
particularly relevant to our thread's topic.
> MSDOS, and presumably FreeDOS, does not natively provide a framework for
> safe filesharing and file locks, this needs to come from the server
> working in combination with requests from the application via the client
If the server software is running on top of a DOS, it either needs to
implement locking separately (in the server application), or it has to
rely on locking being implemented by the DOS kernel.
> Normally when a simple DOS application opens a file it opens it
> in a specific mode, eg read or read/write, and when a file is opened in
> write mode it is opened exclusively, so any process that tried to open
> the file is given an access denied.
If this is meant to refer to the "normal" case of local file system access
without a proper "SHARE" extension loaded on eg MS-DOS and FreeDOS, then
this is incorrect. The problem is that processes are allowed to freely
access the same file in parallel, without any checks going on.
> and another mode for programs that did not like how share.exe worked.
This "other mode" is the "compatibility mode", and it presumably was only
intended to allow older, mode-unaware programs to continue to work.
Unfortunately, even most DOS programs developed after the introduction of
the new modes continued using compatibility mode.
> Share.exe maintains two tables in memory, one for
> each file that is opened, and another for which portions of the file were
> locked, and what mode the portion was locked in
Crucially, the entries in that new file table are unique (that is, each
existing file might have at most one entry) and they link to all entries
in DOS's other (SFT) file table. Lacking the new table, duplicate entries
in the other table are entirely undetected.
> I have run DP over many many different server and networking client
> combinations, with up to about 40 simultaneous connections and not ever
> had a problem unless I was running share.exe on the client
I don't understand how this could have happened. Given what I know,
"SHARE" should only affect access to the local file system. And using it
as opposed to not using it should definitively not cause problems.
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
Freedos-user mailing list