SHARE.EXE and mfs
Brought to you by:
bartoldeman
Menu
▾
▴
#242 SHARE.EXE and mfs
PCBoard BBS tests file sharing/locking and reports a failure on DENY ALL:
DOS's SHARE command is loaded
and PCBoard is set to make network calls
Test SHARE functions:
Open DENY ALL / attempt to share file by second process succeeded - ERROR!
Open DENY NONE / attempt to share file by second process succeeded - OKAY
Attempt to lock record #1 by first process succeeded - OKAY
Attempt to lock record #1 by second process failed - OKAY
Attempt to read record #1 by second process failed - OKAY
Can anyone explain how DOS SHARE.EXE interacts with mfs?
Digging deeper, I think I understand it now.
In mfs.c, DOSEMU uses UNIX locks to emulate the behaviour of DOS SHARE.EXE. But the PCBoard share test runs in a single process, and two opens with O_DENYALL (in the same process) succeed, because UNIX lock semantics allow that. So I wrote a DOS C program to test O_DENYALL from two different processes, using a 10 second sleep after the first lock is acquired. When the first one sleeps, I switch to my second instance of DOSEMU and start the same program.
Bingo! The second process cannot lock the file, reporting a permission denied error.It seems that file sharing/locking will work as expected when two different processes compete for the same file.
Looks like PCBoard wants DOS SHARE.EXE loaded, just to be happy, though SHARE.EXE does nothing except pass the open/lock request to the "network" mfs drive which emulates DOS locking as best it can. Looking at the mfs.c code, I see the emulation is not 100% authentic DOS, but it will probably be good enough for an app like for PCBoard.
I haven't analyzed the code throughly, so my conclusion is part study and part guesswork. If anyone can provide correction or clarification, dont' be shy.