Tramp and VC integration: "calling user"

Tramp and VC integration: "calling user"

[Kai Großjohann]

Tramp advises some VC functions.  It is bad for one package in Emacs
to advise functions in another.

In one of those cases, VC wants to find out if a file is locked by the
calling user.  To do this, VC invokes a command to print the name of
the user who locked the file, and then compares that name with
user-login-name.

For remote files, the comparison should not be with user-login-name,
it should instead be with the user logged into the remote host in
question.

Suggestions for solving this:

(1) New file operation file-mine-p, returns true if the file is owned
    by the "calling user".  For non-special files, the calling user is
    the user who invoked Emacs.  For Tramp files, the calling user is
    the user logged into the remote host.

(2) New file operation file-calling-user, returns the calling user, as
    defined in (1).

(3) Augment the return value of file-remote-p to indicate the calling
    user.  The return value could be augmented to also indicate the
    remote host, if the file is remote.

What do people think?

Kai

Re: Tramp and VC integration: "calling user"

[Stefan Monnier]

> Suggestions for solving this:

> (1) New file operation file-mine-p, returns true if the file is owned
>     by the "calling user".  For non-special files, the calling user is
>     the user who invoked Emacs.  For Tramp files, the calling user is
>     the user logged into the remote host.

> (2) New file operation file-calling-user, returns the calling user, as
>     defined in (1).

> (3) Augment the return value of file-remote-p to indicate the calling
>     user.  The return value could be augmented to also indicate the
>     remote host, if the file is remote.

Could you remind me why file-writable-p can't be used?


        Stefan

Re: Tramp and VC integration: "calling user"

[Kai Großjohann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Suggestions for solving this:
>
>> (1) New file operation file-mine-p, returns true if the file is owned
>>     by the "calling user".  For non-special files, the calling user is
>>     the user who invoked Emacs.  For Tramp files, the calling user is
>>     the user logged into the remote host.
>
> Could you remind me why file-writable-p can't be used?

Well, hm.  What happens if we are in the same group, I check out the
file, it becomes group-writable, then you try to edit it?  (I have no
idea whether a file could become group-writable on checkout, though.)

Perhaps Andre needs to chime in here...

Could be that you have a good point.

Kai

Re: Tramp and VC integration: "calling user"

[Stefan Monnier]

> Well, hm.  What happens if we are in the same group, I check out the
> file, it becomes group-writable, then you try to edit it?  (I have no
> idea whether a file could become group-writable on checkout, though.)

> Perhaps Andre needs to chime in here...

Hmm... actually I can't seem to find the code where the problem shows up.
IIUC the advice you're talking about is on vc-user-login-name which is only
really used in vc-rcs.el, but even there I can't see in what way Tramp's
advice is needed.


        Stefan

Re: Tramp and VC integration: "calling user"

[Andre Spiegel]

On Thu, 2005-03-31 at 08:34 -0500, Stefan Monnier wrote:

> Could you remind me why file-writable-p can't be used?

The conditions "file is writable by the calling user" and "file is
locked by the calling user" are not equivalent.  They can differ if
somebody modifies file permissions deliberately (I've seen this happen
at most sites where RCS is used).  They also differ if RCS is used with
non-strict locking.

VC has lots of code to detect mismatches between the two conditions,
because they do occur all the time in real world situations.  There is
also a special user option, vc-mistrust-permissions, which does
precisely what the name suggests.

So, in short, it is not possible to use file-writable-p.  There needs to
be a way, as Kai described, to compare the name of the calling user and
the name of the locking user as per the RCS master file.

I think the suggestion no. 2, file-calling-user, is best.  Conceptually,
it is something like "user-login-name relative to a given file".  For
files on the local machine, it is the name of the user running Emacs.
For files on a remote machine, it is the name of the user under which
the files are accessed (the login account at the remote machine).
Perhaps it would be worthwhile to add an optional FILE argument to
user-login-name, but it already has an optional argument, UID, so
perhaps a new function, file-calling-user, as Kai suggests, is best.

Re: Tramp and VC integration: "calling user"

[Kai Großjohann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Well, hm.  What happens if we are in the same group, I check out the
>> file, it becomes group-writable, then you try to edit it?  (I have no
>> idea whether a file could become group-writable on checkout, though.)
>
>> Perhaps Andre needs to chime in here...
>
> Hmm... actually I can't seem to find the code where the problem shows up.
> IIUC the advice you're talking about is on vc-user-login-name which is only
> really used in vc-rcs.el, but even there I can't see in what way Tramp's
> advice is needed.

Maybe part of the difficulty is that Tramp's advice is bogus, as I can
now see.  Tramp looks at the owner of the file, that's wrong.

Kai

Re: Tramp and VC integration: "calling user"

[Richard Stallman]

    (1) New file operation file-mine-p, returns true if the file is owned
	by the "calling user".  For non-special files, the calling user is
	the user who invoked Emacs.  For Tramp files, the calling user is
	the user logged into the remote host.

    (2) New file operation file-calling-user, returns the calling user, as
	defined in (1).

    (3) Augment the return value of file-remote-p to indicate the calling
	user.  The return value could be augmented to also indicate the
	remote host, if the file is remote.

#3 seems kludgy, so it shouldn't be that.  I prefer #1.  

Re: Tramp and VC integration: "calling user"

[Andre Spiegel]

On Thu, 2005-03-31 at 23:10 -0500, Richard Stallman wrote:

>     (1) New file operation file-mine-p, returns true if the file is owned
> 	by the "calling user".  For non-special files, the calling user is
> 	the user who invoked Emacs.  For Tramp files, the calling user is
> 	the user logged into the remote host.
> 
>     (2) New file operation file-calling-user, returns the calling user, as
> 	defined in (1).
> 
>     (3) Augment the return value of file-remote-p to indicate the calling
> 	user.  The return value could be augmented to also indicate the
> 	remote host, if the file is remote.
> 
> #3 seems kludgy, so it shouldn't be that.  I prefer #1.  

But #1 is in fact wrong.  It is irrelevant who the owner of the file is
(the same argument as I made concerning file-writable-p).  What must be
tested is whether the name of the locking user, as recorded in the RCS
master file, is that of the calling user.  I still think #2 is the best
way to achieve this.

Re: Tramp and VC integration: "calling user"

[Stefan Monnier]

>> (1) New file operation file-mine-p, returns true if the file is owned
>> by the "calling user".  For non-special files, the calling user is
>> the user who invoked Emacs.  For Tramp files, the calling user is
>> the user logged into the remote host.
>> 
>> (2) New file operation file-calling-user, returns the calling user, as
>> defined in (1).
>> 
>> (3) Augment the return value of file-remote-p to indicate the calling
>> user.  The return value could be augmented to also indicate the
>> remote host, if the file is remote.
>> 
>> #3 seems kludgy, so it shouldn't be that.  I prefer #1.  

> But #1 is in fact wrong.  It is irrelevant who the owner of the file is
> (the same argument as I made concerning file-writable-p).  What must be
> tested is whether the name of the locking user, as recorded in the RCS
> master file, is that of the calling user.  I still think #2 is the best
> way to achieve this.

Am I right in believing that this is a problem specific to vc-rcs.el?
Couldn't vc-rcs.el use RCS directly instead of reproducing RCS's behavior?
I.e. just try a dry-run of `co', and see if it fails?
Or otherwise run (shell-command "id") since shell-command is a fileop that
can be caught by file-name-handlers and run on the remote host.

I just feel that adding a global command is difficult to justify just for
the odd case where all the following conditions are met:
- you're using vc-rcs.el.
- you're using it over Tramp.
- you've played with the permissions such that they don't give us directly
  the proper information about whether a file is locked.


        Stefan

Re: Tramp and VC integration: "calling user"

[Andre Spiegel]

On Fri, 2005-04-01 at 14:14 -0500, Stefan Monnier wrote:

> Am I right in believing that this is a problem specific to vc-rcs.el?

I know of no other occurences, and I'd be happy to localize changes into
vc-rcs.el as much as possible.  Michael Albinus has stated, however (on
tramp-devel), that "such a function is on my wishlist for a while, not
only because of vc."  He didn't give any more details, so I'll put him
in copy and ask him to let us know why he would like something like
"file-calling-user", except for the use in vc-rcs.el.

> Couldn't vc-rcs.el use RCS directly instead of reproducing RCS's
> behavior?
> I.e. just try a dry-run of `co', and see if it fails?

I did things like that when I first made patches to VC, but we decided
against that at the time; it was just too slow, although it is perhaps
clean conceptually.  The "dry-run" of co seems very much like a kludge
to me, though.

> Or otherwise run (shell-command "id") since shell-command is a fileop that
> can be caught by file-name-handlers and run on the remote host.

That sounds like a very interesting alternative, maybe better than
file-calling-user.

> I just feel that adding a global command is difficult to justify just for
> the odd case where all the following conditions are met:
> - you're using vc-rcs.el.
> - you're using it over Tramp.
> - you've played with the permissions such that they don't give us directly
>   the proper information about whether a file is locked.

Well number one is not odd at all, RCS is still a widely used version
control systems at many sites.  Number three is also not very unlikely
-- as I said, I've seen things like that happen at almost every site
where RCS is used.  It is very common that clueless users (or lazy ones)
simply change the permissions of a file to make it "work", without
realizing that they are circumventing RCS this way.  (I got a bug report
from someone who managed to get himself into trouble this way just this
present week.)  VC has the potential to handle these cases much more
gracefully than RCS does on its own.  Number two in your list is what's
not working currently, and we're only trying to achieve it for reasons
of consistency.

As I said, I'd be happy to make the change as local to vc-rcs.el as
possible.  I can certainly envision Tramp-specific code in VC, because
it's just another standard part of Emacs.  But maybe a more general
solution is in fact called for.

Re: Tramp and VC integration: "calling user"

[Richard Stallman]

    > #3 seems kludgy, so it shouldn't be that.  I prefer #1.  

    But #1 is in fact wrong.  It is irrelevant who the owner of the file is
    (the same argument as I made concerning file-writable-p).

I was only talking about how clean these various solutions seem.
Whether any of them is *correct* is another matter--I don't know
about that.  You're the expert on that.  If you think #2 is right
and #1 is wrong, please use #2.

Re: Tramp and VC integration: "calling user"

[Kai Großjohann]

kai@emptydomain.de (Kai Großjohann) writes:

> Suggestions for solving this:
>
> (1) New file operation file-mine-p, returns true if the file is owned
>     by the "calling user".  For non-special files, the calling user is
>     the user who invoked Emacs.  For Tramp files, the calling user is
>     the user logged into the remote host.

I apologize for suggesting the above non-solution.  I don't know what
I was thinking.  Thanks to Andre for setting me straight on this.

> (2) New file operation file-calling-user, returns the calling user, as
>     defined in (1).

This now seems to be the way to go.  I'm not happy with the name,
though.  Names that crossed my mind for this operation:
file-calling-user, file-standard-user, file-user-login-name.  I don't
like any of them.

Do people have a better suggestion?

> (3) Augment the return value of file-remote-p to indicate the calling
>     user.  The return value could be augmented to also indicate the
>     remote host, if the file is remote.

I agree with Richard that this seems kludgy.

Kai

Re: Tramp and VC integration: "calling user"

[Michael Albinus]

Andre Spiegel <spiegel@gnu.org> writes:

> On Fri, 2005-04-01 at 14:14 -0500, Stefan Monnier wrote:
>
>> Am I right in believing that this is a problem specific to vc-rcs.el?
>
> I know of no other occurences, and I'd be happy to localize changes into
> vc-rcs.el as much as possible.  Michael Albinus has stated, however (on
> tramp-devel), that "such a function is on my wishlist for a while, not
> only because of vc."  He didn't give any more details, so I'll put him
> in copy and ask him to let us know why he would like something like
> "file-calling-user", except for the use in vc-rcs.el.

I don't remember the concrete case when I've missed such a
function. Likely it was when I've worked on tramp-minor-mode,
integrating Tramp with other packages like "compile.el".

Best regards, Michael.