Re: [Savannah-hackers-public] Read-only files in www's CVS repository

[Sylvain Beucler]

Hi,

It turns out that somebody activated 'cvs watch on' at a point.  This
on a CVS feature where you need to 'cvs edit' before modifying a file,
which triggers the 'notify' hook.
http://www.network-theory.co.uk/docs/cvsmanual/Settingawatch.html

This creates CVS/fileattr files on the server, which is how I spotted
the issue.

You can issue a 'cvs watch off' at the root of the working copy (which
I just did) to recursively cancel this.

I also removed 2 remaining 'CVS/fileattr' files (which referenced
removed files in Attic/ and were not removed; they were harmless, but
it's cleaner this way).


Btw,
> I only reported it here after performing the things in this bullet
> list; I know you're busy and I still feel guilty about that nefarious
> translations project renaming.

There's nothing to be guilty about :)
However, was there progress with renaming the translation project
webpages? I think the renaming stalled there.

-- 
Sylvain

On Sat, Jun 14, 2008 at 03:49:46AM +0300, Yavor Doganov wrote:
> Sylvain Beucler wrote:
> > 
> > I had a look at po/ and it doesn't look different than the rest of
> > the CVS files at Savannah :/
> 
> Too bad, it basically rules out my theory.
> 
> > Files are created 444 _on the server_ but that's the way CVS set
> > permissions for all repositories.
> 
> This is where the oddity comes from.
> 
> * I examined CVSROOT and compared it with other repositories (both Web
>   and Sources) and I ensured that there are no special things for www
>   (I wanted to report the problem to www maintainers first with the
>   hope that somebody knows what's going on, but concluded that it's
>   not a request made explicitly (in the past) by a www maintainer).
> 
> * I tested this with a Web and Sources reposotory of another project
>   (trans-coord), and I also checked all cvs logs of all the files in
>   the www repository (of course only in the root directory plus the
>   subdirectories I know were created after 2005; doing this on every
>   file is almost equal to a suicide).  By doing so, I was able to
>   determine the fact that permissions for newly added files since that
>   date (or year, more "precisely") were read-only, and I all newly
>   added sub-directories were read-only -- naturallly because they
>   inherit the permissions of the parent directory.
> 
> * I initally thought this was my fault, so I checked all the recent
>   commits (in the past 3 years, which turned to be a lot) that I was
>   sure were done by me (only using Debian and gNewSense machines).
> 
> * Once I figured out that even people `cvs add'-ing files from a
>   Fedora, certainly-non-Debian or Windows (that's a felony in my book,
>   but nevertheless) distros and only happening after 2005 and only on
>   www, and only in the root directory + all sub-directories created
>   after that suspected date, I decided to report it here.
> 
> * I suspected a bug in CVS, and even a bug introduced in
>   Debian-specific change of the cvs package since sv.gnu.org runs
>   Debian and my machines run either Debian or gNewSense.  So I checked
>   the Debian changelog and the bugs in Debian; it smells very much
>   like http://bugs.debian.org/10448 but I know that if such a bug was
>   present many Savannah users would yell.
> 
> * I checked out the source of the Debian `cvs' package and examined the
>   patches (there are a lot), in the hope that this is an obvious typo
>   that is reproduced only in the peculiar Savannah setup for www since
>   about 2005.  No clues, but of course no guarantees either -- I
>   surely may miss something.
> 
> I only reported it here after performing the things in this bullet
> list; I know you're busy and I still feel guilty about that nefarious
> translations project renaming.
> 
> > Can you detail where you see them as read-only (client or server?),
> 
> If you do a cvs export or checkout of www, and then `ls -l' in the
> root, you will observe that some files are 644, but some are 444.
> 
> Then (assuming you have repository write permissions and naturally a
> working copy):
> 
> touch foo
> cvs add foo
> touch gnu/foo
> cvs add gnu/foo
> cvs commit ...
> 
> Will result in `foo' being read-only while `gnu/foo' being 644.  If
> you add `contact/foo', it will be read-only as well, because the
> /contact directory was added after 2005.  Likewise, adding
> `philosophy/foo' will yield read-write permissions, because
> /philosophy was created before this bad event in 2005 (according to my
> unproven theory).
> 
> > and what major gried this causes with the new translation system?
> 
> The build system modifies files that exist in the working copy (after
> `cvs update') so every command that touches such a file fails.  I
> workaround this with chmod currently, but there seems to be a general
> problem.
> 
> FWIW, I noticed about this weirdness in www (and only in www!) many
> many months ago, but because of some RCS reflex/habit, I usually do
> `C-x v v' in Emacs without much thinking when the buffer is not
> writable.  So it is kinda embarrassing that I did not anticipate the
> build failure in the official `www' repository... 
> 
> Anyway, the workaround does the job, so this is not something urgent.
> 
> > Give me steps to reproduce your problem :)
> 
> I believe I gave them, but unfortunately I made tests only on
> Debian-based machines (no other system at my disposal).  If anything
> else is necessary, of course I think I can easily provide it.
>