In a previous blog entry on accessing Subversion repositories by means of SMB shares, I lamented the rejection of my APR patch that works around some of the problems and put forth two possible options for future efforts:
- Rewrite the patch for Subversion instead of APR since the issue seems to primarily affect Subversion.
- Try to hack the smbfs implementation in Mac OS X, which is based on the SMB protocol and filesystem implementation for FreeBSD.
Further investigation of the smbfs implementation indicates that hacking it many not be the best solution. If fact, engineers at Apple have also had to work around the file locking issues that cause problems with Subversion. Notice this quote from a message in the cocoa-dev mailing list regarding SQLite, which is one of the data stores used for Core Data:
For SMB (Samba), SQLite will use flock() style locks. Since there is no way to upgrade a shared flock() lock to an exclusive flock() lock without offering a window of time within which another app can effectively ‘steal’ the lock, flock() based locks will only support exclusive locks.
Since Apple engineers have found this work-around to be effective, then it makes sense for me to pursue the option of rewriting the patch instead of trying to update the Mac OS X smbfs implementation.
I have begun development of this new patch, but may finish it after Mac OS X v10.5 Leopard is released. The reason for this is that the new version of Mac OS X may contain some improvements in the smbfs implementation and I don’t want to spend a lot of time working around issues if Apple might fix them in Leopard. Of course, the current patch will continue to work with the current Mac OS X v10.4 Tiger.
Working Copies on SMB Filesystems
I’ve had two people email that Subversion working copies also have a problem when used on SMB filesystems. I don’t see why anyone would want to store their working copies on a network file server, but I’m sure they have a good reason for doing it. :-)
The problem occurs when attempting to commit or update the working copy, which fails because of a permissions error similar to the example shown here.
svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: In directory '/Volumes/bwells/svn_test'
svn: Error processing command 'committed' in '/Volumes/bwells/svn_test'
svn: Error replacing text-base of 'test.txt'
svn: Can't move '/Volumes/bwells/svn_test/.svn/tmp/text-base/test.txt.svn-base' to '/Volumes/bwells/svn_test/.svn/text-base/test.txt.svn-base': Permission denied
After a bit of troubleshooting, I figured out what is causing the permissions error. Each directory of a Subversion working copy contains a sub-directory named .svn that holds files used to track the status of the working copy in relation to the repository. All files within the .svn directory are marked as read-only to prevent accidental tampering. On Windows this is accomplished by setting the read-only file attribute and on Mac OS X by adjusting the UNIX-style file permissions.
When compiled for Windows, Subversion includes a few lines of code that will remove the read-only file attribute before attempting to delete or replace these files. Otherwise, these file operations on the working copy would fail with a permissions error.
When compiled for Mac OS X, Subversion does not include the code to remove the read-only file attribute since the UNIX-style permissions used by Mac OS X allow read-only files to be removed or overwritten.
It is possible to develop a patch for Subversion so that for Mac OS X files that are on a SMB share are handled specially when they are to be deleted or replaced. However, the read-only file attribute is not exposed through the SMB filesystem in Mac OS X 10.4. The only way to adjust the read-only file attribute is by means of the smbclient command-line utility’s setmode command, but this would be quite difficult to incorporate into a patch.
The best work-around is to checkout the working copy from a Macintosh instead of from a Windows computer. Subversion will attempt to mark the files as read-only by adjusting the file permissions, but this will quietly fail since the real file permissions on the Windows computer are not represented on the mounted SMB share in Mac OS X. Of course, the problem will reappear as soon as Subversion is used to modify the working copy from a Windows computer.
Support for mounting SMB shares could improve in a future release of Mac OS X so that the problem is eliminated entirely or a suitable patch for Subversion can be made.