Subject: Re: bug#51622: 29.0.50; [PATCH v2] Abbreviate remote home directories in `abbreviate-file-name'

From: Michael Albinus <[email-masked]>
Date: Mon, 08 Nov 2021 16:58:11 +0100

Jim Porter <[email-masked]> writes:

Hi Jim,

> Hmm, actually it turns out that my patch was only this fast because I
> forgot to check whether the host has case-sensitive file names or
> not. Adding that check back in slows things down again. How I update
> my previous patch will depend on whether we can make
> `file-name-case-insensitive-p' fast for Tramp files, so I'll just
> focus on this part for now and then follow up on the other parts of
> your message after we've decided on what to do here.
>
> Currently on case-sensitive hosts,
> `tramp-handle-file-name-case-insensitive-p' performs its checks on the
> connection every time this function is called. The beginning of
> tramp.el says the following:
>
>   * `tramp-case-insensitive'
>     Whether the remote file system handles file names case insensitive.
>     Only a non-nil value counts, the default value nil means to
>     perform further checks on the remote host.  See
>     `tramp-connection-properties' for a way to overwrite this.
>
> I interpret this to mean that Tramp *intentionally* performs checks on
> the host every time if the result is nil.

No. It just means, that the value of `tramp-case-insensitive' in
`tramp-methods' is used only if it is non-nil. BUT there is also a check
for a connection property "case-insensitive", and that value is used if
it exists, be it nil or non-nil. Therefore, the whole check in
`tramp-handle-file-name-case-insensitive-p' is applied only once, and
afterwards the cached connection property is used.

See the saved connection properties in file ~/.emacs.d/tramp.

> Is there a reason this is necessary?

The data in `tramp-methods' are static. By default, only non-nil values
are relevant, and we shouldn't change this w/o any need, since we have
connection properties for dynamic data.

> Are there any systems out there where the check would return nil, but
> it's still case-insensitive in some cases? Even if there are, I
> imagine that *most* of the time, this check is reliable, and it would
> be nice if we could cache the result for case-sensitive hosts.

See the comment in `tramp-handle-file-name-case-insensitive-p':

--8<---------------cut here---------------start------------->8---
  ;; We make it a connection property, assuming that all file systems
  ;; on the remote host behave similar.  This might be wrong for
  ;; mounted NFS directories or SMB/AFP shares; such more granular
  ;; tests will be added in case they are needed.
--8<---------------cut here---------------end--------------->8---

So we cache the result, even if it might be problematic. But honestly, I
haven't seen reports yet about such a problem.

> I've attached the beginnings of a patch to do this. What do you think?
> If the general idea makes sense, I'll finish it up and file a separate
> bug to track it. If Tramp needs to perform the checks every time for
> some remote hosts, maybe the user could set `tramp-case-insensitive'
> to `never-cache' for those connections?

Before we start such changes, we should understand your case. Why is it
computed every time? Why isn't the cached value used?

Can you debug? The cache for "case-insensitive" is read by

--8<---------------cut here---------------start------------->8---
(with-tramp-connection-property v "case-insensitive" ...
--8<---------------cut here---------------end--------------->8---

If there isn't a cached value, this macro evaluates its body, and sets
the cache.

You might set tramp-verbose to 7, and follow entries in the debug buffer like

--8<---------------cut here---------------start------------->8---
16:26:43.718831 tramp-get-connection-property (7) # case-insensitive undef; cache used: nil
16:26:43.729457 tramp-set-connection-property (7) # case-insensitive nil
16:26:43.734749 tramp-get-connection-property (7) # case-insensitive nil; cache used: t
--8<---------------cut here---------------end--------------->8---

> I hope your health is doing better now.

It will be up and down, as it happens for years. You will see me to
disappear for some days in the future, from time to time. That's (my) life.

Best regards, Michael.