ls-lisp and remote files

ls-lisp and remote files

[Lars Hansen]

  I have been working on making ls-lisp work for remote files. To do 
that I have made a Tramp implementation of 
directory-files-and-attributes using perl on the remote machine. This 
works fine except for the translation of UID's and GID's to names. To 
make this translation, ls-lisp calls user-login-name which works in the 
context of the local machine, and that is wrong for remote directories. 
Of cource one could just let ls-lisp check if the directory is remote 
and make no translation if it is. However, I sugest the following:

1. Add an optional parameter ID-NAMES to the lisp functions 
file-attributes and directory-files-and-attributes. When ID-NAMES is 
non-nil, UID and GID is returned as names if possible.

2. Let ls-lisp use this feature to obtain UID and GID names.

I have implemented these change on my own machine (dired.c, lisp.h, 
ls-lisp.el, tramp.el) and it seems to work fine.

I want to ask people what you think about this suggestion.

----------------

One more related thing.
IFAICS it is a bug that the current implementation of ls-lisp calls 
user-login-name to obtain group name. user-login-name calls getpwuid, 
but getgrgid should be used for that, I think. It might work on 
GNU/Linux systems but it fails on Sun systems, at least the one I have 
access to. On the Sun system UID's and GID's are not disjoint.
With the changes I suggest above there is no need to make a lisp 
interface to getgrgid since the translation may be done in dired.c.

Re: ls-lisp and remote files

[Stefan Monnier]

> I have implemented these change on my own machine (dired.c, lisp.h,
> ls-lisp.el, tramp.el) and it seems to work fine.

> I want to ask people what you think about this suggestion.

I think this was requested already in the past and it would be
good to have.  Maybe someone else remembers better in which context
this came up and what was done about it.


        Stefan

Re: ls-lisp and remote files

[Kai Grossjohann]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I have implemented these change on my own machine (dired.c, lisp.h,
>> ls-lisp.el, tramp.el) and it seems to work fine.
>
>> I want to ask people what you think about this suggestion.
>
> I think this was requested already in the past and it would be
> good to have.  Maybe someone else remembers better in which context
> this came up and what was done about it.

I had a similar problem with remote VC.  Now Tramp does weird stuff to
circumvent the numerical ids problem, I think.  I think the most
recent workaround is that Michael made it so that Tramp invents user
ids for remote files and maintains its own mapping between user id and
user name.  But that doesn't make sense.

I also remember that I looked in the whole Emacs source tree (Lisp
part only, though) to see if the numerical id is ever actually used.
It turned out that what the code really wants is the user name.

So I believe it would be good to at least offer the code the ability
to request names instead of numbers, and to then convert the existing
code to the names.  Then, VC could work without those kludges.

Warning: I'm out of the loop now and my memory is hazy, quite possibly
this is wrong.  *sigh*  Later, I'll be able to invest more brains into
this, I hope.

Kai

Re: ls-lisp and remote files

[Stefan Monnier]

> I also remember that I looked in the whole Emacs source tree (Lisp
> part only, though) to see if the numerical id is ever actually used.
> It turned out that what the code really wants is the user name.

That's what I remember as well.
I think we should simply switch to user-names, but if compatibility
is a problem, we can just provide an additional argument to select
between the two behaviors.


        Stefan

Re: ls-lisp and remote files

[Lars Hansen]

Stefan Monnier wrote:

>I think we should simply switch to user-names, but if compatibility
>is a problem, we can just provide an additional argument to select
>between the two behaviors.
>
Just switching to names rather than numbers for user id and group id 
sounds appealing to me -- then we wouldn't have to introduce an 
additional parameter to file-attributes and directory-files-and-attributes.

What is most important here, simplicity or compatibility?

Re: ls-lisp and remote files

[Richard Stallman]

    > It turned out that what the code really wants is the user name.

    That's what I remember as well.
    I think we should simply switch to user-names, but if compatibility
    is a problem, we can just provide an additional argument to select
    between the two behaviors.

It sounds good to me.

Re: ls-lisp and remote files

[Lars Hansen]

[-- Attachment #1.1: Type: text/plain, Size: 851 bytes --]

>
>
>>I also remember that I looked in the whole Emacs source tree (Lisp
>>part only, though) to see if the numerical id is ever actually used.
>>It turned out that what the code really wants is the user name.
>>    
>>
>
>That's what I remember as well.
>I think we should simply switch to user-names, but if compatibility
>is a problem, we can just provide an additional argument to select
>between the two behaviors.
>  
>
I have done some searching in the source tree myself now. There are no 
problems in the C code, but in the lisp code I have found more that 10 
files that expects UID to be numeric. It may be true that all of them 
can be changed to use names rather than ids, but it requires more work 
than I can handle myself. Therefore I suggest we introduce an additional 
argument to file-attributes and directory-files-and-attributes.

[-- Attachment #1.2: Type: text/html, Size: 1157 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
Tramp-devel mailing list
Tramp-devel@nongnu.org
http://mail.nongnu.org/mailman/listinfo/tramp-devel

Re: ls-lisp and remote files

[Richard Stallman]

    I have done some searching in the source tree myself now. There are no 
    problems in the C code, but in the lisp code I have found more that 10 
    files that expects UID to be numeric. It may be true that all of them 
    can be changed to use names rather than ids, but it requires more work 
    than I can handle myself. Therefore I suggest we introduce an additional 
    argument to file-attributes and directory-files-and-attributes.

I think would be better, because the result would be cleaner overall,
if we changed all those ten files.  Are there people who want to do that?

Re: ls-lisp and remote files

[Lars Hansen]

Richard Stallman wrote:

>I think would be better, because the result would be cleaner overall,
>if we changed all those ten files.  Are there people who want to do that?
>  
>
I agree that it would be cleaner.

Let me list the lisp files that I think need to be changed:

      files.el
      ls-lisp.el
      tramp.el
      vc-sccs.el
      fast-lock.el
      server.el
      vc-rcs.el
      find-lisp.el
      info.el
      net/tramp.el
      net/tramp-smb.el
      net/ange-ftp.el
      net/tramp-vc.el
      eshell/esh-util.el
      eshell/em-ls.el
      eshell/em-unix.el
      eshell/em-pred.el
      gnus/nneething.el
      mail/blessmail.el

Re: ls-lisp and remote files

[Richard Stallman]

    Let me list the lisp files that I think need to be changed:

If the changes are trivial, and especially if the changes make things
cleaner, then I think it is a good idea.  Returning numbers here is
ugly, and it would be good to get rid of that ugliness.

Re: ls-lisp and remote files

[Lars Hansen]

>
>
>If the changes are trivial, and especially if the changes make things
>cleaner, then I think it is a good idea.  Returning numbers here is
>ugly, and it would be good to get rid of that ugliness.
>  
>
I agree that always returning strings is the best solution. But it 
requires a lot of thorough code reading to be sure that the changes 
required really are trivial and to make those changes without 
introducing bugs. Much more work than I can handle myself. I understand 
from Kai and Stefan that these changes have been considered before, but 
that nothing was done. I fear that the same might happen again. And I 
think that introducing an optional parameter is better than doing noting 
at all. But if you can convince some people to work on these changes, 
maybe even someone with knowledge of some of the modules, I will gladly 
participate.

Re: ls-lisp and remote files

[Richard Stallman]

I agree that adding an option is better than nothing.

The option should be designed so that there is a non-nil value meaning
"numbers" and another non-nil value meaning "strings", so that we can
someday change the meaning of nil.

Re: ls-lisp and remote files

[Kevin Rodgers]

Richard Stallman wrote:

> The option should be designed so that there is a non-nil value meaning
> "numbers" and another non-nil value meaning "strings", so that we can
> someday change the meaning of nil.

How about any number (e.g. 0) or any string (e.g. "")?


-- 
Kevin Rodgers

Re: ls-lisp and remote files

[Andreas Schwab]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Richard Stallman wrote:
>
>> The option should be designed so that there is a non-nil value meaning
>> "numbers" and another non-nil value meaning "strings", so that we can
>> someday change the meaning of nil.
>
> How about any number (e.g. 0) or any string (e.g. "")?

Or maybe 'numberp and 'stringp.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ls-lisp and remote files

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> Kevin Rodgers <ihs_4664@yahoo.com> writes:
> 
> > Richard Stallman wrote:
> >
> >> The option should be designed so that there is a non-nil value meaning
> >> "numbers" and another non-nil value meaning "strings", so that we can
> >> someday change the meaning of nil.
> >
> > How about any number (e.g. 0) or any string (e.g. "")?
> 
> Or maybe 'numberp and 'stringp.

The original proposal has the advantage that

(setq x (what-were-we-talking-about x))

will retain the type.  Almost as easy would be to use the values

(type-of 0) and (type-of "")

(after evaluation, of course).  There is no similarly straightforward
mapping from a number to 'numberp and a string to 'stringp AFAIR.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: ls-lisp and remote files

[Richard Stallman]

      Almost as easy would be to use the values

    (type-of 0) and (type-of "")

Those values are `integer' and `string'.  I like that approach.

Re: ls-lisp and remote files

[Lars Hansen]

Richard Stallman wrote:

>The option should be designed so that there is a non-nil value meaning
>"numbers" and another non-nil value meaning "strings", so that we can
>someday change the meaning of nil.
>  
>
I like that idea. How about this:

We introduce a parameter ID-FORMAT with the following meaning:
If ID-FORMAT is numeric or nil, UID and GID are returned as integers, 
otherwise as strings.

Over time we can change all calls so they include ID-FORMAT with a value 
of 0 or t, and we can try to avoid using 0. Once the lisp source has no 
calls with ID-FORMAT left out, we can change the meaning of nil such 
that UID and GID are returned as strings in that case. Then we can 
remove the parameter from the calls where it has value t, and if the 
parameter then is unused, we may even remove it from the definition.

These plans should be written in the lisp manual and the TODO file, I think.

Re: ls-lisp and remote files

[Kai Grossjohann]

Lars Hansen <larsh@math.ku.dk> writes:

> Richard Stallman wrote:
>
>>I think would be better, because the result would be cleaner overall,
>>if we changed all those ten files.  Are there people who want to do that?
>>
>>
> I agree that it would be cleaner.
>
> Let me list the lisp files that I think need to be changed:

It seems I should participate here.

>       tramp.el
>       net/tramp.el
>       net/tramp-smb.el
>       net/tramp-vc.el

These are easy because they really want to have strings, and so all
that's needed is to remove the kludges.

I'm afraid that I can't promise to work on this soon; Real Life is
taking its toll.  But it's now on my todo list.

And then, of course, it's quite possible that Michael Albinus will be
faster than me.  He's always been in the past couple of months.  Kudos
to Michael.

>       net/ange-ftp.el
>       vc-rcs.el

For these, I have a vague idea that maybe I can figure out what's
needed.  Doesn't sound that promising, right?

Kai