Mail Archives: djgpp/1998/03/19/13:41:00
>
>> With the help of gdb and a couple of printfs, I seem to have issolated
>> the problem. The function, chnamemod(), in rcsedit.c is trying
>> to un_link() a nonexistant file. In my case I am trying to check in
>> newfile.c for the first time. ci creates ,newfile.c on the NFS drive
>> just fine. ci tried to un_link newfile.c,v before renaming ,newfile.c
>> to newfile.c,v, and this failed because the file isn't there.
>
>Do I inderstand correctly that this same code succeeds on a local
>drive but fails on a remote drive?
Yes, everything works fine on the local drive, but the network drive
has a problem.
>If so, please post the code fragment that calls `un_link' and handles
>its possible errors. (I don't have the RCS sources handy at this
>time.) It seems that removing a non-existent file should always fail,
>so I suspect RCS doesn't handle the failure correctly, or doesn't
>expect to get EACCES in errno after such failures.
With a failed un_link RCS checks errno. If its set to ENOENT, then
rcs is happy. Since the network drive returns a EACCESS failure,
rcs complains. On the local drive, the un_link sets errno to ENOENT.
>> In my configuration, the call to un_link() is actually a #define
>> to unlink() which is in libc.a.
>
>I attach the source code of `remove' from the library at the end of
>this message (`unlink' just jmp's to `remove'). If the above
>assumption about errno value is not true, please paste the source of
>`remove' into one of the RCS source files, then rebuild the programs
>and step with a debugger into `remove' when it tries to unlink
>newfile.c,v. I would like to know what part of the function fails and
>how (i.e., with what DOS code).
The DOS error code returned in r.x.ax is 5 which the function doserr_to_errno
translates to an EACCESS.
>> I wonder if I should change conf.h so that has_NFS is 1 instead of
>> defined to 0.
>
>What does defining has_NFS do to RCS?
>
Turning on has_NFS changes un_link from being a #define to unlink() to
an actual function call in rcsedit.c. I tried it and it didn't really
change the behavior. It did give me a convenient place to check for
the existance of the file before trying to remove it. This work around
gets me just about to where I wanna be: being able to easily share
rcs archives between UNIX and win95 via NFS.
The last problem I seem to have is related to locking preexisting ,v files.
If UNIX user Jane checks in a revision of file foo.c, Jane is the owner
of the associated ,v file. Now if win95 NFS user matt tries to lock the
file, rcs complains of an EACCES error. However, UNIX user matt, can
lock the file eventhough Jane owns it. Truely fixing the un_link problem
instead of my work around will probably fix this problem as well, maybe.
Matthew H. Gerlach
- Raw text -