I downloaded the source for sshfs and examined it. I see that if there's an error with rename and the workaround is enabled, it will rename the target file to a temporary name with random characters appended. Then it does the same rename it attempted originally, and then deletes (unlinks) the file with the temporary name.
In debug mode, I would expect to see at least four operations go by. (Failed initial rename, successful temporary rename, successful initial rename again, and a successful delete.) But I don't see that. Aside from a couple LOOKUP operations, I see only the failed RENAME operation. I will look for a way to get more information from the debug option. I am currently using the command: sshfs [EMAIL PROTECTED]:/afs /afs -oworkaround=rename,debug I am trying to see what sshfs does so that I can give my sysadmins a simple example that they can see using SFTP instead of requiring them to install fuse and sshfs themselves. On Dec 9, 10:42 am, "[EMAIL PROTECTED]" <lsloan- [EMAIL PROTECTED]> wrote: > Yes, I will check with the administrators of my sftp and AFS servers. > Since sshfs could rename files on the local disk of the sftp server, > but not those in AFS via the same server, I think that there must be > some additional complexity added by AFS. > > Thank you for explaining the workaround behavior. If I run MacFuse > and/or sshfs in verbose debug mode, does the output indicate when > initial rename fails and the workaround has been attempted? When the > workaround uses a temporary name, what name does it use? > > I'll try to get the source code for sshfs and see what I can interpret > from that. > > On Dec 8, 9:15 pm, Amit Singh <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
