Update pyhesiodfs snapshot to add /mit/.locker support

[geofft]

   sipb / lockers / broder  15:16  (Evan Broder)
       geofft: pyhesiodfs already can do /mit/.locker
-> sipb / lockers / broder  15:16  (Evan Broder)
       The code is in git/svn/whatever. I just haven't updated Debathena's
       snapshot of the code
   sipb / lockers / broder  15:16  (Evan Broder)
       File a ticket or something

[broder]

It was pointed out a while back that some applications (e.g. git) will look all the way up the directory tree to find magic dotfiles or dot-directories, so having, e.g. /mit/.git, automatically exist could be a potentially weird behavior.

Given that, I'm not sure we actually want to fix this.

[broder]

Even if /mit/.git is the only actual risky behavior we know about here, that's enough to convince me that the side-effects from /mit/.locker support are way more serious than the benefits. Plus you can always ln -nsf anyway.

[andersk]

Hey, what about /.mit/locker instead?

[achernya]

/.mit seems slightly annoying because it involves another whole mountpoint. Could we perhaps do something weirder in /mit/, perhaps /mit/.#? I'm not aware of any programs that look of .#foo files.

[jweiss]

Replying to achernya:

/.mit seems slightly annoying because it involves another whole mountpoint. Could we perhaps do something weirder in /mit/, perhaps /mit/.#? I'm not aware of any programs that look of .#foo files.

That's exactly the convention used by Athena delete/expunge. I don't think there's a technical conflict, here, since the expunger only runs in AFS, but it still seems like it has the potential for confusion

[andersk]

/.mit/locker parallels /afs/.athena.mit.edu/path in a way that makes sense, while .#locker looks like editor backup sputum. What's wrong with another whole mountpoint?