>> (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
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
