[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Problem with file permission after update

From: Giulio Troccoli <Giulio.Troccoli_at_uk.linedata.com>
Date: Thu, 3 Jul 2008 12:55:36 +0100

I'm having a problem with the file permissions of new files which seem
to be wrong after an update of an existing working copy.

- The working copy exists already and the permissions are fine on them.
- A post-commit hook exist to update this working copy automatically
- A user commits a new directory with new files
- After the commit the file permissions on the new files are wrong.

Now, let me explain what I mean by wrong. I would expect the permissions
to be -rw-rw-rw- on all files, instead they are -rw-r--r--. The real
problem is not the files themselves but the .svn directory and the files
within have the wrong permission. This causes automatic merge to fail
because Subversion cannot open the .svn/lock file, permission denied.

I thought it was a matter of umask being wrong, but all parties
involved, user, root and svn (which is the user that apache runs as),
have umask set to 000.

The only solution I found is to log in as svn, i.e. the user running
apache, delete the new directory from the working copy and running an
update. This does indeed restore the missing directory and files AND
with the correct permission based on the umask of svn user.

My server and client are both 1.4.4, with Apache 2.0 on a RHEL4 server.

It's a bit difficult to write down a script to replicate it, but if you
need more info or me to try something just let me know.

Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-03 13:57:09 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.