Enhancement for file-attributes

Enhancement for file-attributes

[Eli Zaretskii]

Would it be a good idea to enhance file-attributes by adding one more
optional argument to it, which, when non-nil, will cause Emacs call
'stat', not 'lstat', on the argument file name?  This should avoid the
need to call file-chase-links when all we want is to get the
attributes of the file pointed to by the symlink.

Re: Enhancement for file-attributes

[Paul Eggert]

On 09/30/2012 07:26 AM, Eli Zaretskii wrote:
> Would it be a good idea to enhance file-attributes by adding one more
> optional argument to it, which, when non-nil, will cause Emacs call
> 'stat', not 'lstat', on the argument file name?

Yes, thanks, I've wanted that myself in the past.  This seems like a
no-brainer so I installed it as trunk bzr 110295.

Re: Enhancement for file-attributes

[Eli Zaretskii]

> Date: Sun, 30 Sep 2012 14:14:14 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 09/30/2012 07:26 AM, Eli Zaretskii wrote:
> > Would it be a good idea to enhance file-attributes by adding one more
> > optional argument to it, which, when non-nil, will cause Emacs call
> > 'stat', not 'lstat', on the argument file name?
> 
> Yes, thanks, I've wanted that myself in the past.  This seems like a
> no-brainer so I installed it as trunk bzr 110295.

Thanks.

Re: Enhancement for file-attributes

[Stefan Monnier]

> This seems like a no-brainer so I installed it as trunk bzr 110295.

Seems like it, but changing the signature of such core function is not
always as harmless as it seems.
E.g. have you committed corresponding changes to Tramp?


        Stefan

Re: Enhancement for file-attributes

[Paul Eggert]

On 09/30/2012 05:45 PM, Stefan Monnier wrote:
> have you committed corresponding changes to Tramp?

Good point, and I won't have time to wade through the Tramp mess before the
feature-freeze tomorrow, so I reverted that change to file-attributes
in trunk bzr 110303.  Some other time perhaps.

Re: Enhancement for file-attributes

[Michael Albinus]

Paul Eggert <eggert@cs.ucla.edu> writes:

Hi Paul,

> Good point, and I won't have time to wade through the Tramp mess before the
> feature-freeze tomorrow, so I reverted that change to file-attributes
> in trunk bzr 110303.  Some other time perhaps.

If you plan to add this feature again, you could contact me. I will help
you fighting the Tramp mess.

Best regards, Michael.

Re: Enhancement for file-attributes

[Stefan Monnier]

> Would it be a good idea to enhance file-attributes by adding one more
> optional argument to it, which, when non-nil, will cause Emacs call
> 'stat', not 'lstat', on the argument file name?  This should avoid the
> need to call file-chase-links when all we want is to get the
> attributes of the file pointed to by the symlink.

It would have made a lot of sense originally, but I'm wondering whether
it's worth the trouble now.  In how many places would we save the
file-chase-links all?  Are these places important?


        Stefan

Re: Enhancement for file-attributes

[Juanma Barranquero]

On Mon, Oct 1, 2012 at 3:16 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> It would have made a lot of sense originally, but I'm wondering whether
> it's worth the trouble now.  In how many places would we save the
> file-chase-links all?  Are these places important?

I don't know about that, but a way to ask file-attributes for a
specific value, instead of computing them all and consing them into a
list would perhaps make sense.

I recently counted uses of (nth X (file-attributes ...)), and
variants, like (car (file-attributes ...)) and (let ((atr
(file-attributes ...))) ...), etc. Asking for the file size happens >
110 times in the sources; last modification time, > 50; all the rest,
<10 each (approx, as I counted by hand).

So a function (file-size X) doing an optimized equivalent of  (nth 7
(file-attributes (file-truename NAME))) would be useful, and cleaner
IMO.

    Juanma

Re: Enhancement for file-attributes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sun, 30 Sep 2012 21:16:31 -0400
> 
> > Would it be a good idea to enhance file-attributes by adding one more
> > optional argument to it, which, when non-nil, will cause Emacs call
> > 'stat', not 'lstat', on the argument file name?  This should avoid the
> > need to call file-chase-links when all we want is to get the
> > attributes of the file pointed to by the symlink.
> 
> It would have made a lot of sense originally, but I'm wondering whether
> it's worth the trouble now.

What trouble can this make?  An additional argument whose default is
nil should never cause any trouble.  Am I missing something?

> In how many places would we save the file-chase-links all?  Are
> these places important?

One place is in files.el: after-find-file, when we visit a file that
is a symlink, and backup-buffer.  These are quite frequently used
APIs.

Re: Enhancement for file-attributes

[Stefan Monnier]

>> In how many places would we save the file-chase-links all?  Are
>> these places important?
> One place is in files.el: after-find-file, when we visit a file that
> is a symlink, and backup-buffer.  These are quite frequently used APIs.

So you're saying it's important because it can impose
a noticeable overhead in those cases?  Do we have actual numbers?
It seems that both operations do so many other things that it might be
lost in the noise.


        Stefan

Re: Enhancement for file-attributes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Mon, 01 Oct 2012 10:31:58 -0400
> 
> >> In how many places would we save the file-chase-links all?  Are
> >> these places important?
> > One place is in files.el: after-find-file, when we visit a file that
> > is a symlink, and backup-buffer.  These are quite frequently used APIs.
> 
> So you're saying it's important because it can impose
> a noticeable overhead in those cases?  Do we have actual numbers?

No, I don't, at least not on Posix systems.  On MS-Windows, chasing
links is expensive, but that might be because the equivalent of
'readlink' is slower than on Posix.

> It seems that both operations do so many other things that it might be
> lost in the noise.

Maybe so, but it's a boon to the programmer to pass one more argument
instead of invoking another API, I think.  And I see no danger in the
change of the interface.