Ticket #370 (closed task: wontfix)
Update pyhesiodfs snapshot to add /mit/.locker support
| Reported by: | geofft | Owned by: | broder |
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
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
Change History
comment:2 Changed 15 years ago by broder
- Status changed from new to closed
- Resolution set to wontfix
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.
comment:4 follow-up: ↓ 5 Changed 11 years ago by 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.
comment:5 in reply to: ↑ 4 Changed 11 years ago by 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
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.