A problem, a fix and a request

[Gregg Leichtman]

I ran into a "problem" with CVS v1.11.15 that is still present in
v1.12.11. I wished to cvs checkout a sandbox onto a NFS drive mounted on
a Solaris 8 system. The drive is exported from a Windows 2000 Pro system
using a PC NFS server. The mounted drive has rwx rights for the root
owner and for the user's group doing the checkout.
 
Checkout proceeds just fine for the first folder of files until an
attempt by cvs is made to rename the Entries.Backup file to Entries in
the leaf CVS folder before moving on to the next folder of files to be
checked out. This fails, since cvs attempts to do a rename_file in
entries.c. This works fine under Solaris where the libc rename function
simply overwrites the Entries file with the renamed Entries.Backup file
(essentially doing a mv -f Entries.Backup Entries). Unfortunately, under
Windows through NFS (and maybe outside of NFS), this mapping fails,
since the rename is not forced and Windows complains about renaming a
file over an existing file and punts. Searching across the net, I
discovered more than one person had run into this problem and no direct
solution had been offered. Since I am doing cvs checkouts from a bash
script running under Solaris, I don't have the option of using a Windows
client to checkout the sandbox to the Windows box directly and cygwin is
not an option due to several bugs I ran into in attempting to use it for
my purpose.
 
Therefore, I went and changed the cvs client code in entries.c in the
1.12.11 release as follows:
 
/* now, atomically (on systems that support it) rename it

Changed by Gregg Leichtman, 09Mar2005

This is an attempt to fix a problem where a sandbox is checked out to a
mounted NFS directory served from a Windows 2000 NFS server.
The problem rectified with the new code is to avoid using rename which,
on UNIX systems does essentially a forced move but on Windows systems
attempts to non-forcefully rename one file over the top of an existing
file with the same name. This is not allowed under Windows and causes an
I/O error when an attempt is made to rename the Entries.Backup file to
Entries.

The "fix" is to replace the atomic rename operation with a non-atomic
copy and unlink. Since this is happening inside the user's sandbox,

I don't think an atomic operation is needed. I could be wrong.

rename_file (entfilename, CVSADM_ENT); */

copy_file (entfilename, CVSADM_ENT);                        // added by
GSL
if (unlink_file (entfilename) && !existence_error (errno))  // "
        error (0, errno, "unable to remove %s", entfilename); // "

My request is to incorporate this change into the official code base,
_IF_ I have not missed some fundamental implication of this change. I'm
not sure why the rename needs to be atomic in this case, since my
understanding is that only one person would work on a sandbox at a time.
The code also indicates that the rename on some OS' is not atomic. Does
anyone see a problem with this? If not, can it be incorporated?

                       -=> Gregg <=-
 

----

Gregg Leichtman, Ph.D.

Digital Imaging Specialist
leichtman@radpharm.com

Dark corners are basically fractal - no matter how much you illuminate,
there's always a smaller but darker one.

- Brian Kernighan

There is a foolish corner in the brain of the wisest man.

- Aristotle

Long experience has taught me this about the status of mankind with
regard to matters requiring thought: the less people know and understand
about them, the more positively they attempt to argue concerning them,
while on the other hand to know and understand a multitude of things
renders men cautious in passing judgment upon anything new.

- Galileo

 





This message is intended for the exclusive use of the individual or entity that 
is the named addressee and may contain information that is privileged or 
confidential. If you are not the named addressee or an employee or agent 
responsible for delivering this message to the named addressee, you are not 
authorized to read, print, retain, copy or disseminate this message or any part 
of it. If you have received this message in error, please notify us immediately 
by e-mail, discard any paper copies and delete all electronic files of the 
message