2

Motivation / Background

  • I use the ffap counterparts of common file- and directory-finding commands, i.e. find-file-at-point, dired-at-point et al. in place of find-file, dired et al., respectively.
  • I want to set ffap-file-finder (the file-finding subroutine defaulting to find-file which ffap uses behind the scenes) to counsel-find-file from the counsel package.
  • counsel-find-file returns a plain, non-TRAMP-qualified filename, in contrast with find-file et al. which return the buffer visiting the given file.
  • I thus want to write a function suitable as a value for ffap-file-finder (i.e. one that returns a buffer object) using counsel-find-file (which returns a plain filename).

Observations

I have tried calling find-buffer-visiting on the filename returned by counsel-find-file, but this approach breaks down when the file in question has been opened with TRAMP sudo syntax. Using the file /etc/pam.conf with inode 123 and device number 456 on host foo as an example, I have made the following observations in such cases:

;; This actually calls `(find-file "/sudo:root@foo:/etc/pam.conf")' internally
(counsel-find-file) ; => "/etc/pam.conf"

;; These follow the call to `counsel-find-file'
(get-buffer "pam.conf")                       ; => #<buffer pam.conf>
(get-file-buffer "pam.conf")                  ; => nil
(get-file-buffer "/etc/pam.conf")             ; => nil
(find-buffer-visiting "pam.conf")             ; => nil
(find-buffer-visiting "/etc/pam.conf")        ; => nil
(nthcdr 10 (file-attributes "/etc/pam.conf")) ; => (123 456)

Inside the buffer of the sudo-opened "/etc/pam.conf" file:

buffer-file-name   ; => #("/sudo:root@foo:/etc/pam.conf" 6 10 (tramp-default t))
buffer-file-number ; => (123 (-1 . 1))

AFAICT, (find-buffer-visiting "/etc/pam.conf") fails when "/etc/pam.conf" has been opened via TRAMP because find-buffer-visiting:

  • compares the given plain filename with the TRAMP-syntax values of buffer-file-name and buffer-file-truename; and
  • compares both inode and device numbers to determine file equality, but TRAMP seems to modify the device number.

Questions

  1. Is it necessary for TRAMP to change the file-attribute-device-number of visited files? If so, why?
  2. How does TRAMP compare files for equality in such cases?
  3. Given a plain, non-TRAMP-qualified filename, how do I lookup a TRAMP buffer visiting it?
  4. How do I make find-buffer-visiting work with TRAMP buffers?

(These questions overlap, but I would like to cover all bases.)

Addendum

I realise that I can call (get-buffer (counsel-find-file)) in my example, but I fear this is not a robust approach in the face of multiple buffers with uniquified names visiting the same file. I am also curious as to whether there is a more general and "correct" TRAMP solution to my questions.

  • Perhaps you should raise a bug report to get counsel-find-file to return more useful results? Or, assuming it strips the tramp context on purpose, to implement an analog function which does not do that? – phils Oct 31 '17 at 1:47
  • @phils I have already raised such an issue about counsel-find-file returning a filename instead of a buffer, but note that counsel-find-file: a) is not the main focus of my question; b) does not strip any Tramp context; and c) does not claim to be a drop-in find-file replacement. – Basil Oct 31 '17 at 1:54
2

In summary of the spawned tramp-devel thread:

Is it necessary for TRAMP to change the file-attribute-device-number of visited files? If so, why?

Different Tramp methods are inherently treated as separate filesystems, so device numbers must differ across them. Virtual numbers are generated as required to ensure this.

How does TRAMP compare files for equality in such cases?

It cannot currently and does not need to. This is theoretically implementable, but of little apparent merit.

Given a plain, non-TRAMP-qualified filename, how do I lookup a TRAMP buffer visiting it?

How do I make find-buffer-visiting work with TRAMP buffers?

To quote Michael directly:

Look for (concat "/sudo::" filename) or alike.

1

This are a lot of questions, not easy to answer. And they will need to discuss.

I fear that stackexchange is not the proper place for this. I recommend you to ask at the Tramp mailing list <tramp-devel@gnu.org>.

  • Thanks. Although I have read through the TRAMP manual in the past I admit I had forgotten about its mailing list. Do you think I should leave my question open for now? – Basil Oct 24 '17 at 12:44
  • Here is the relevant thread for posterity lists.gnu.org/archive/html/tramp-devel/2017-10/msg00029.html – Basil Oct 24 '17 at 20:40
  • 1
    Thanks, I've seen. Will answer next days (being a little bit overloaded just now). And yes, I believe you could leave your question open, if you plan to add a summary of the findings, later on. – Michael Albinus Oct 25 '17 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.