[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-help-public] [sr #105364] non-project member has 'cvs watch' a
Derek Robert Price
[Savannah-help-public] [sr #105364] non-project member has 'cvs watch' and is causing problems
Mon, 26 Jun 2006 19:33:19 +0000
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20060508 Firefox/188.8.131.52
Follow-up Comment #7, sr #105364 (project administration):
First, please purge all the CVS/ directories. That will get rid of the
dbowles edits and won't lose anything vital.
Second, to answer your permissions question, CVS needs write permissions only
to the archive directories when writing achives for a number of reasons. At
the most basic, CVS writes new archives to a temp file and then moves the
complete file over the old version, and this only requires write permissions
to the directory since ext2/3 filesystems without ACLs in use treat this as a
file creation, a file deletion, then a rename, all of which only require write
permissions to the new directory.
Looking a little deeper, CVS updates archives this way because RCS did and
CVS imported most of the original RCS code. RCS did things this way because
it used the temp file as a file lock on the archive and probably because it
has the secondary effect of not corrupting an archive file when writes are
interrupted by a system or disk crash.
CVS/fileattr is not handled this way only because no one ever thought it was
necessary. Locking this file was never necessary because CVS locks the
entire parent directory before writing file attrs and CVS simply opens the
CVS/fileattr file and begins writing to it, which requires write permissions
to the file. As for system crashes, a corrupt CVS/fileattr is not nearly as
potentially devastating as a corrupt archive file.
Reply to this item at:
Message sent via/by Savannah