Since your issue occurs even at the sftp level (no sshfs or MacFUSE involved), you need to debug it at that level if you're really interested in solving this. You'll need to debug either the AFS server or the sftp server--perhaps both--to see what exactly is failing.
I should point out that "workaround=rename" is *ON* by default in the sshfs binary I distribute. So, even when you weren't using that option, it was there. Take a look at sshfs.c in the sshfs source to see what it does: specifically, look at sshfs_rename(). In a pinch, if the initial rename attempt fails because of an EPERM and the target file already exists, it moves the target to a temporary name, performs the rename, and unlinks the temporary file. Amit On Dec 8, 5:47 pm, "[EMAIL PROTECTED]" <lsloan- [EMAIL PROTECTED]> wrote: > I tried this earlier after I read the explanation of the problem in > that sshfs FAQ. > Using sftp to connect to my remote server and access the directory on > the AFS volume, I issued the appropriate rename command: > > sftp> pwd > Remote working directory: /afs/umich.edu/path/to/project/.svn > sftp> rename tmp/entries entries > Couldn't rename file "/afs/umich.edu/path/to/project/.svn/tmp/entries" > to "/afs/umich.edu/path/to/project/.svn/entries": Failure > > To determine whether the files' location in AFS had any bearing upon > this, I copied the files to a local filesystem (/tmp) on the remote > server. The sftp rename failed in the same way. > > That's very interesting to me, since I didn't have any problem > renaming (mv'ing) the file in the servers own filesystem when I had it > mounted on my Mac via sshfs. That was without the workaround=rename > option, too. > > To set the scene for my environment, my local computer also has: > > Mac OS X 10.4.11 > SFTP protocol version 3 > OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006 > > The remote server: > > Linux server.umich.edu 2.6.21.3 #3 SMP Thu Jun 28 15:52:05 EDT 2007 > i686 GNU/Linux > SFTP protocol version 3 > OpenSSH_4.6p1-hpn12v17, OpenSSL 0.9.7l 28 Sep 2006 > > What does sshfs *do* to work around the sftp rename problem when the > workaround=rename option is used? > > On Dec 8, 6:55 pm, Amit Singh <[EMAIL PROTECTED]> wrote: > > > Leave sshfs out of the picture. > > > Use sftp (the standard command-line program) to connect to the machine/ > > volume in question. Try the "rename" command within sftp to do the > > same rename. Does *this* rename work? > > > Amit > > > On Dec 4, 1:05 pm, "[EMAIL PROTECTED]" <lsloan- > > > [EMAIL PROTECTED]> wrote: > > > I have tried the workaround option and removed some of the earlier > > > options: > > > > sshfs [EMAIL PROTECTED]:/afs /afs -oworkaround=rename > > > > And I still get the same error. > > > > From some of the text on that sshfs FAQ, it sounds as if the rename > > > problem has been fixed since v1.3. So I tried another test that > > > mounts the local disk of a remote system. It turns out that as long > > > as AFS isn't in the equation, svn works well with sshfs even *without* > > > the workaround=rename option. > > > > This leads me to believe it's more of a problem with accessing AFS > > > than the way renames work through sftp. > > > > On Dec 4, 2:07 pm, Amit Singh <[EMAIL PROTECTED]> wrote: > > > > > On Dec 4, 10:52 am, "[EMAIL PROTECTED]" <lsloan- > > > > > [EMAIL PROTECTED]> wrote: > > > > > Thank you for the very *friendly* reply! > > > > > Sure. > > > > > A Google search for +svn +sshfs +rename yields (http:// > > > > fuse.sourceforge.net/wiki/index.php/SshfsFaq): > > > > > ==== > > > > Why does SVN (etc...) fail to rename files? > > > > > $ svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs > > > > svn: Can't move 'kdelibs/.svn/tmp/entries' to 'kdelibs/.svn/entries': > > > > Operation not permitted > > > > The reason is that SFTP protocol version 3 (which is implemented by > > > > OpenSSH's sftp-server) defines the rename operation slightly > > > > differently than POSIX. The difference is that renaming to an existing > > > > file or directory will fail instead of atomically replacing the old > > > > file. > > > > > The -o workaround=rename option will try to emulate POSIX rename > > > > semantics, but it cannot guarantee atomicity. In most of the cases > > > > this doesn't matter, and things will work fine with this option. > > > > ==== > > > > > What's the output of "sshfs -V" on your system? > > > > > Amit --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to macfuse-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
