> 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
