Thank you for the very *friendly* reply!

Yes, I've been trying this command:

  sshfs-static [EMAIL PROTECTED]:/afs /afs -
odefer_permissions,sshfs_debug,debug,volname=afs

That doesn't seem to make a difference at all, which is why I asked my
earlier question.

Specifically, I want to work with a directory of files in AFS that was
checked out of a Subversion repository.  I want to add a file to the
project:

  svn add foo.bar

I get this error:

  svn: Can't move '.svn/tmp/entries' to '.svn/entries': Operation not
permitted

However, if I perform the same command on the remote host that is an
AFS client, it works without problem.

On my Mac, with AFS mounted via sshfs, I tried to move that file
manually:

  mv .svn/tmp/entries .svn/entries

And I received a similar error:

  mv: rename .svn/tmp/entries to .svn/entries: Operation not permitted

However, if I copy the file to the destination and remove the
original, it works:

  cp -p .svn/tmp/entries .svn/entries ; rm .svn/tmp/entries

You have probably noticed that I am using the debug options as well.
Amongst the output, I find these messages:

unique: 0, opcode: RENAME (12), nodeid: 351, insize: 64
RENAME /umich.edu/path/to/project/.svn/tmp/entries -> /umich.edu/path/
to/project/.svn/entries
[00579] RENAME
  [00578]         STATUS       28bytes (6ms)
  [00579]         STATUS       28bytes (6ms)
[00580] RENAME
  [00580]         STATUS       28bytes (2ms)
[00581] RENAME
  [00581]         STATUS       28bytes (1ms)
[00582] RENAME
  [00582]         STATUS       28bytes (3ms)
   unique: 0, error: -1 (Operation not permitted), outsize: 16

Not much indication of why the operation wasn't permitted.

So I throw my request out to this group.  If anybody has ideas about
this, please let me know.  I've also tried setting umask, uid, and gid
options, but none of those seemed to make a difference.

Interestingly, I didn't have a problem with this project when it was
using CVS for version control.  Since it switched to svn, I have these
problems.

On Dec 4, 1:06 pm, Amit Singh <[EMAIL PROTECTED]> wrote:
> You didn't try searching at all, did you?
>
> Try the "-odefer_permissions" mount-time option.
>
> Amit
>
> On Dec 4, 8:42 am, "[EMAIL PROTECTED]" <lsloan-
>
> [EMAIL PROTECTED]> wrote:
> > When a filesystem is mounted vi sshfs, what is checking the
> > permissions on files and directories?  Is it sshfs, MacFuse, Mac OS X,
> > or the remote server?
>
> > I am mounting a remote server that is an AFS client.  I need to access
> > some files and directories that are in the AFS hierarchy on that
> > server.  For the most part, traditional file permission modes, owners,
> > and groups on directories are meaningless in AFS.  In our AFS space,
> > users don't do much with owner and group settings on directories and
> > they choose somewhat random modes.  For example, the mode of a
> > directory may say that it's not writable and I'm not the owner or in
> > the group listed for the directory, but if the AFS access control
> > lists (ACLs) say that I can write to the directory, then I can do it.
> > The same applies to the execute mode bits, they are unimportant, I can
> > change into a directory that doesn't have the execute bit set if the
> > ACLs let me do it.
>
> > The problem I have now is that these directories in AFS don't have the
> > execute bit set, so I can't access them through sshfs.  So I think
> > that sshfs, MacFuse, or Mac OS X is evaluating the mode on those
> > directories and not letting me in.  Is there some way to prevent that
> > local evaluation?  Just send the request to the remote server and if
> > it gets denied there, then report an error?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to