[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A problem, a fix and a request
A problem, a fix and a request
Thu, 10 Mar 2005 09:10:05 -0500
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
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
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
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
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.
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.
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
- A problem, a fix and a request,
Gregg Leichtman <=