Re: Tramp and VC integration: "calling user"

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> (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