Our web development company has a Linux server with a Samba share which employees use to develop websites. On the Samba share are numerous directories which serve as document roots for a webserver (folder client/website.domain on the share matches http://some.website.local/). Each project has Git or Subversion managed repositories. Both Windows and Mac clients connect to the Samba share. The Windows machines have no issues working with the share. The Mac clients, however, have.

Since our recent switch to Git I started noticing a pattern in the errors. Occasionally, when doing a commit or an update in Subversion, the SVN client would choke and present a rather vague error. The working copy would be locked, and the only way to work with that working copy again was unmounting and remounting it. Only then could we run an svn cleanup and get the working copy operable again.

The same thing now happens with Git. Sometimes when someone does a pull, all the files get updated, but the index file can't be written. So the Git client thinks the changes just pulled from the remote repo are in fact unstaged changes made by the user, since the index file wasn't updated it thinks it still reflects an older copy of the repo.

So, both SVN and Git work with metadata (the files stored in .svn and .git). It's those files that often become locked in some sort of way. It never occurs with normal files. We have tried numerous settings in the smb.conf file on the Linux machine regarding oplocks and other related settings, but still to no avail. It's starting do drive us a little bonckers here.

Has anyone had any similar experiences? So far I googled like mad, but haven't found anything.

  • just for clarification, you are using the mounted shares to edit files that will be pulled into Git? If yes, can't this concurrency be the source of your problem? – fboaventura Feb 19 '13 at 17:03
  • Thanks for your reply; the project directories all are either a Subversion working copy or a Git working copy (having a remote that points to our internal Git server for pulling/pushing). Each employee uses his own checkout. The file system structure is actually client/website/employee, which translates to http:// employee.website.client.internal/ -- Anyway, I'm quite sure it has something to do with writing metadata. Problems occur only when updating SVN/Git working copies, not on normal file operations, like saving source files. – Leon Boot Mar 4 '13 at 13:13

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.