There are several places in the code where git calls open() with the
flag
O_EXCL. This causes a problem for us when the current directory is on an
NFS-mounted NTFS volume shared by an NAS fileserver. The open fails with
"EACCES: Permission denied", even though the user has full read/write
permissions on the target directory.
I used a tiny C program to confirm that the O_EXCL flag is the culprit;
removing that flag from the open() call allows the open to succeed. Of
course, the call also succeeds, with the O_EXCL flag in place, if the
current directory is on an NFS-mounted UNIX filesystem.
We're looking into ways to work around this; one way would be to hack
the git
source and remove all the O_EXCL flags (are they really needed?), but
I'm
afraid that might break git in horrible ways. Another way might be to
mount
the NTFS volume via CIFS instead of NFS. But first I wanted to ask if
anyone
here can offer a solution based on changing our git configuration or
our NFS
mount options or the NTFS volume settings. (At present we have no
gitconfig
file, so all settings are default).
Git version is 1.6.5.3, running on x86_64 RHEL-4, kernel 2.6.9-89.
The error
the user sees is:
> cd /WWW
> git init
fatal: cannot copy '/usr/local/share/git-core/templates/info/exclude' to
'/WWW/.git/info/exclude': Permission denied
Using strace, we can see the offending call:
open("/WWW/.git/info/exclude", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1
EACCES
(Permission denied)
We know the user has permission to create this file because he can cd
into
/WWW/.git/info and copy exclude there from the templates directory by
hand.
--
Kai Lanz Stanford University School of Earth Sciences
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html