> Just curios, why are you using --fs-type bdb?
I just copied this line for the test script from a previous bug report.
Actually for my real data I am using a repository over HTTPS (and I
guess that server uses Linux with a native Linux file system), so the
repository layout and protocol are not relevant.
> Do you see working copy corruption if you run your sequence of
commands
> on a native Linux filesystem, like ext3?
No. Running the script in my previous post on an ext4 file system gives
the same results as you had (non-root user access is denied, since they
have no write permissions, but working copy is not corrupted).
> I don't think you can rely on the permission bit fields coming from
> the NTFS filesystem because NTFS doesn't have UNIX-permission
semantics.
I just want all users to have full access to all files and directories
on the NTFS partition, no user mapping.
Now I found the culprit in /etc/fstab: if I the omit gid=users option
(and use e. g. option 'defaults' or 'exec' or whatever) then the problem
is gone. This satisfies my needs, since I just want all users to have
full access to all files and directories on the NTFS partition.
This solution obviously does not work if one wants only some users to
have only some users access the partition (i. e. make use of the gid
option).
II guess the problem might be like that: svn renames its metadata files
to some temporary names (this succeeds because it has rwx permissions),
then for some reason, it tries to set the permissions or owner of
temporary files and crashes because changing the permissions is not
allowed. Interestingly, the following script succeeds on a native Linux
file system (i. e. if /windows is not mounted but just a directory in
the ext4 file system /):
cd /windows
sudo svnadmin create repos
sudo svn co file:///windows/repos/ aa
sudo chmod -R a+rwx aa
svn up aa
sudo svn log aa
As you can see, this script creates on a native Linux file system a
situation similar to the script of my previous post on an NTFS file
system: I added chmod to give the non-root user rwx permissions.
Although the user does not own the /windows directory and hence has no
rights to change permissions of its subdirectories and files (e. g.
"chmod a+r /windows/aa" fails), "svn up aa" succeeds for some reason in
this case, on my computer.
All in all, I think that it would be nice to have at least bug b) (that
svn corrupts the working copy's .svn directory) fixed. Also it is
possibly confusing for the user and worth investigation that svn behaves
differently with NTFS-3g and native Linux file systems in case the user
has rwx permissions but no right to change permissions.
Best regards,
Jaan
Received on 2010-12-25 20:03:04 CET