Dos Library
6 messages in this thread
Andy;
Last weekend I read a conversation between you and some other person
dealing with the DOS library, it appeared that you really knew what you
were doing. Therefore, if you don't mind I have a question for you. I have
noticed that MODE_READWRITE of the Open() call in the dos library works
differently in 2.04 than it did for 1.3. In 1.3 it was simply an exclusive
access version of MODE_OLDFILE. With 2.04 MODE_READWRITE works exactly
like MODE_OLDFILE except that it will create the file if it doesn't already
exists. With MODE_OLDFILE the file must already exist. The way it is now
I have no way of opening an existing file with exclusive access like I
could with 1.3. My question is, why was a documented mode changed, or is
the change a bug. If the change was deliberate then it seems to me that a
fourth mode should have been created instead of changing an existing one.
If you could enlighten me I sure would appreciate it.
Ed
There should not have been any particular change. The implementation of
the modes is done at the file system level. What we have is three
different modes:
MODE_OLDFILE = 1005 – If file does not exist, return an error. Open the
file with a shared lock.
MODE_NEWFILE = 1006 – If file exists, delete it first. Open the file
with an exclusive lock.
MODE_READWRITE = 1004 – If file does not exist, create it. Open the file
with a shared lock.
So, as you observe, there is no way to open an existing file with an
exclusive lock. To solve this, 2.0 introduced a new packet –
ACTION_FH_FROM_LOCK = 1026. You can lock the file in exclusive mode and
then call OpenFromLock() to convert the lock to a file handle (opened in
exclusive mode). Obviously this is a 2.0 only solution. I can't account
for the workings in 1.3, which handler is it that you are dealing with?
John A. Toebes, VIII – via Whap!
Hmmm, might be a bug in the filesystem. You can use OpenFromLock to get an
exclusive lock on an existing file under 2.0; But I can check if a design
change was made.
andy
John;
Your exactly right, the modes you showed in your message are the way 2.0
is. The problem is that 1.3 isn't that way or at least versions earlier
than 1.3.2. MODE_READWRITE acted exactly the same as MODE_OLDFILE except
that it was an exculive lock. This is how MODE_READWRITE acted in my
programs and also the 1.3 include files show the same thing. Below is the
include that deals with this.
* Mode parameter to Open() MODE_OLDFILE EQU 1005 * Open
existing file read/write * * positioned at
beginning of file. MODE_NEWFILE EQU 1006 * Open freshly created
file (delete * * old file) read/write
MODE_READWRITE EQU 1004 * Open old file w/exclusive lock
With OpenFromLock this is not a problem, but it sure messed up my
multi-user bulliten board. As soon as I installed 2.0 it started acting
funny and that is why I noticed the difference. So it looks to me like
there was a design change that caught me. Thanks for your reply.
Ed
Andy;
I think it was a design change. I delieve Commodore shouldn't have made a
design change like that because it was documented the old way.
MODE_READWRITE first came out in 1.2 and the Enhancer manual showed it.
It's also showed the old way in the 1.3 include files listed below.
* Mode parameter to Open() MODE_OLDFILE EQU 1005 * Open
existing file read/write * * positioned at
beginning of file. MODE_NEWFILE EQU 1006 * Open freshly created
file (delete * * old file) read/write
MODE_READWRITE EQU 1004 * Open old file w/exclusive lock
I'd appreciate it if you would look into it and see if it was a design
change.
Ed
I've still got to check on it; its possible that 1.3 FFS worked the same
was 2.0 does, and that 1.3 OFS was different.
andy