mountrefactor branch
Floris Bruynooghe
I've updated all the implementations in the mountrefactor branch (but
someone should check the darwin code). The rationale for the changes
in this branch are in
http://groups.google.com/group/psi-discuss/msg/edec26261b2eb003 if you
need to check.
Anyway, I was wondering if Erick is happy with these changes, since he
created the original implementation currently in trunk (err, default
branch). Does it cover all your use cases and do you agree it's an
improvement, or at least status-quo? If so I'd like to merge it in
the default branch.
Cheers
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
Chris Miles
On 01/08/2009, at 7:15 AM, Floris Bruynooghe wrote:
> I've updated all the implementations in the mountrefactor branch (but
> someone should check the darwin code). The rationale for the changes
> in this branch are in
> http://groups.google.com/group/psi-discuss/msg/edec26261b2eb003 if you
> need to check.
Looks great to me. All the attributes work fine on OS X 10.5.7 (and
all tests pass).
We may need to think more about our strategy for detecting remote
mounts, as my smb mounts are treated as local. The device for one, for
example, is "//chris@myth/downloads". Is that device format a
standard we can rely on, so any devices of that form specifying
"@host" could be considered remote?
Cheers,
Chris
Erick Tryzelaar
Is that what it says when you run mount? Maybe we check if the mount
type is smb as well.
Floris Bruynooghe
This is an issue indeed (and I must admit I haven't tested remote
mounts). It seems we just look for ':' which is the way NFS mounts
are distinguished.
According to the manpage of the syntax of smb mounts is
"//<host>/path/on/host" where "<host>" can be a hostname or IP
address (and according to your example can include a username - I'm
happy with ignoring that and including it in the .host attibute).
This seems a rather tricky problem since Linux and Solaris (and
MacOSX?) don't really tell you if it's remote or not (AIX does). It
gets even worse with user-space filesystems (e.g. sshfs[0]), how will
we ever know if they're remote or not? So it looks like the only
solution we have is special-case the remote filesystems we know about.
:-(
Oh and if a real path includes a ':' or someone starts the normal
mount point with '//' by accident (which the kernel happily converts
to a single '/' and carries on) we end up being wrong too. I guess
we'll just have to live with these cases.
Regards
Floris
PS: Erick, since you didn't complain loudly I'll assume you're fine with
merging this.
[0] sshfs is actually nice since it plays according to the de-facto
rules set by NFS of having '<host>:<path>' with the odd case of
<path> being allowed to be empty. It would have been easy for
smb/cifs to have done the same but they seem to have missed that
opportunity.
Erick Tryzelaar
Bruynooghe<floris.b...@gmail.com> wrote:
>
> PS: Erick, since you didn't complain loudly I'll assume you're fine with
> merging this.
Yep, no complaints.
Chris Miles
What if we flag "remote" according to fstype and rely on a list of
fstypes that are considered remote which the user can override at call
time?
For example, the default might be
remote_fstypes=('nfs', 'smbfs')
To override that the user passes their own sequence to mounts():
mounts = psi.mount.mounts(remote_fstypes=('nfs',))
Otherwise I'm worried our heuristic for determining what is remote or
not based on device string is not going to please everyone.
Cheers
Chris
Floris Bruynooghe
Not a bad idea, but how can we know what to put in the .host attribute
this way? I don't fancy asking for or parsing a regular expression or
something like it.
Floris