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  
> software
> working in combination with requests from the application via the client
> networking.

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

Reply via email to