bug#58360: 28.2; tramp-archive and file-directory-p

bug#58360: 28.2; tramp-archive and file-directory-p

[Gustavo Barros]

Hi All,

I'm not sure this one is really a bug.  But I've met a behavior which 
was surprising enough to me that I thought better check if it is really 
intended.

The thing started with `counsel-find-file' which, instead of opening an 
ODT file as I wished to do, would auto mount a volume on the system and 
then navigate inside it as a directory.

I went down the rabbit hole, and it turns out that `file-directory-p' 
returns `t' for an ODT file appended with a slash.  And the reason it 
does is that `tramp-archive' is enabled by default, and that 
OpenDocument format extensions are included in `tramp-archive-suffixes'.

So, if you try:

    (file-directory-p (expand-file-name "~/file.odt/"))

provided that "~/file.odt" exists, will return `t' on an "emacs -Q" 
session.

Is this really intended?  It was baffling to me (to the point that I've 
personally set `tramp-archive-enabled' to nil, as Tramp's manual taught 
me to), but perhaps there are use cases which I'm missing that may 
justify it.

A side comment on this.  Even assuming this is intended behavior, is it 
really the case to bundle up every file type extension supported by 
"libarchive" in `tramp-archive-suffixes'?  There may be people who wish 
to navigate into "tar", "iso", "rar" or "zip" files as directories.  But 
why should this be the default for OpenDocument formats, or for "exe", 
or "deb" files, for example, for which the desired behavior is likely 
something else?

Furthermore, `tramp-archive-suffixes' is a defconst, not a defcustom. 
So users are stuck with "all or nothing", unable to select for which 
file types tramp-archive should be used or not.  (Of course, I know one 
can always change things regardless, but that's not the point.)

Best regards,
Gustavo.



In GNU Emacs 28.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, 
cairo version 1.16.0)
 of 2022-09-12 built on gusbrs-laptop
Windowing system distributor 'The X.Org Foundation', version 
11.0.12013000
System Description: Linux Mint 20.3

Configured using:
 'configure --with-mailutils --with-xwidgets --with-native-compilation
 --without-compress-install'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: pt_BR.UTF-8
  value of $LC_NUMERIC: pt_BR.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils tramp-archive
tramp-gvfs tramp-cache zeroconf url-util url-parse url-vars dbus xml
tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat
shell pcomplete comint ansi-color ring parse-time iso8601 time-date
ls-lisp format-spec auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs cl-loaddefs cl-lib password-cache json subr-x map seq
byte-opt gv bytecomp byte-compile cconv iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 90884 5482)
 (symbols 48 8618 0)
 (strings 32 26749 1709)
 (string-bytes 1 909860)
 (vectors 16 17076)
 (vector-slots 8 353786 11826)
 (floats 8 31 242)
 (intervals 56 227 0)
 (buffers 992 12))

bug#58360: 28.2; tramp-archive and file-directory-p

[Stefan Kangas]

Gustavo Barros <gusbrs.2016@gmail.com> writes:

> I went down the rabbit hole, and it turns out that `file-directory-p'
> returns `t' for an ODT file appended with a slash.  And the reason it
> does is that `tramp-archive' is enabled by default, and that
> OpenDocument format extensions are included in `tramp-archive-suffixes'.
>
> So, if you try:
>
>     (file-directory-p (expand-file-name "~/file.odt/"))
>
> provided that "~/file.odt" exists, will return `t' on an "emacs -Q"
> session.

I can reproduce this on current master using:

    0. touch /tmp/file.odt
    1. emacs -Q --batch -eval \
        '(message "%s" (file-directory-p (expand-file-name "/tmp/file.odt/")))'

I get this output on stderr:

    t
    Tramp: Unmounting /tmp/file.odt

Maybe Michael has some ideas (in Cc).

bug#58360: 28.2; tramp-archive and file-directory-p

[Gustavo Barros]

Hi Stefan,

On Fri, 07 Oct 2022 at 22:51, Stefan Kangas <stefankangas@gmail.com> 
wrote:

> I can reproduce this on current master using:
>
>     0. touch /tmp/file.odt
>     1. emacs -Q --batch -eval \
>         '(message "%s" (file-directory-p (expand-file-name 
>         "/tmp/file.odt/")))'
>
> I get this output on stderr:
>
>     t
>     Tramp: Unmounting /tmp/file.odt
>
> Maybe Michael has some ideas (in Cc).

Thanks for checking.

Putting things in this form made me think of something else which might 
be worth discussing as well.  Running the predicate alone is enough to 
trigger the mounting of the file.  Isn't this overstepping?

Best regards,
Gustavo.

bug#58360: 28.2; tramp-archive and file-directory-p

[Michael Albinus]

Gustavo Barros <gusbrs.2016@gmail.com> writes:

> Hi All,

Hi Gustavo,

> The thing started with `counsel-find-file' which, instead of opening
> an ODT file as I wished to do, would auto mount a volume on the system
> and then navigate inside it as a directory.
>
> I went down the rabbit hole, and it turns out that `file-directory-p'
> returns `t' for an ODT file appended with a slash.  And the reason it
> does is that `tramp-archive' is enabled by default, and that
> OpenDocument format extensions are included in
> `tramp-archive-suffixes'.
>
> So, if you try:
>
>    (file-directory-p (expand-file-name "~/file.odt/"))
>
> provided that "~/file.odt" exists, will return `t' on an "emacs -Q"
> session.
>
> Is this really intended?  It was baffling to me (to the point that
> I've personally set `tramp-archive-enabled' to nil, as Tramp's manual
> taught me to), but perhaps there are use cases which I'm missing that
> may justify it.

This is intended. There is no need for packages like counsel to check

(file-directory-p (expand-file-name "~/file.odt/"))

It is a misuse to add a slash to an existing regular file and pray that
it works. There has been a similar error in ange-ftp, see bug#56078. It
has fixed. I recommend to contact the counsel author for a fix.

> A side comment on this.  Even assuming this is intended behavior, is
> it really the case to bundle up every file type extension supported by
> "libarchive" in `tramp-archive-suffixes'?  There may be people who
> wish to navigate into "tar", "iso", "rar" or "zip" files as
> directories.  But why should this be the default for OpenDocument
> formats, or for "exe", or "deb" files, for example, for which the
> desired behavior is likely something else?

There might be people who wish to navigate into "odt", "exe", or "deb"
files. It shall be possible. It happens only if you access
"/path/to/file.odt/" (the trailing slash is important), for which there
is no other desired behavior I could imagine.

> Furthermore, `tramp-archive-suffixes' is a defconst, not a
> defcustom. So users are stuck with "all or nothing", unable to select
> for which file types tramp-archive should be used or not.  (Of course,
> I know one can always change things regardless, but that's not the
> point.)

I doubt that people would change such a user option. What would be the
use case? There is still tramp-archive-enabled, and if a package really
really really wants to access "file.odt/" for another purpose than the
intended, the package shall let-bind this variable.

> Best regards,
> Gustavo.

Best regards, Michael.

bug#58360: 28.2; tramp-archive and file-directory-p

[Michael Albinus]

Gustavo Barros <gusbrs.2016@gmail.com> writes:

> Hi Stefan,

Hi Gustavo,

> Putting things in this form made me think of something else which
> might be worth discussing as well.  Running the predicate alone is
> enough to trigger the mounting of the file.  Isn't this overstepping?

tramp-archive.el is implemented by using the archive backend of
GVFS. This means, that the file is mounted via fuse.

I wish we would have another implementation, for example integrating
libarchive(3) directly into Emacs. This would avoid mounting, and it
would allow us to use it on other platforms but GNU/Linux only. But
nobody has implemented this yet.

It is on my TODO under the section "When I really run out of ideas what
to do else". But this section doesn't get attention by me yet.

Anybody else is invited to implement a native libarchive(3) integration
into Emacs, as I have said several times already. Should we add this on
etc/TODO?

> Best regards,
> Gustavo.

Best regards, Michael.

bug#58360: 28.2; tramp-archive and file-directory-p

[Stefan Kangas]

Michael Albinus <michael.albinus@gmx.de> writes:

> Anybody else is invited to implement a native libarchive(3) integration
> into Emacs, as I have said several times already. Should we add this on
> etc/TODO?

Makes sense to me.

bug#58360: 28.2; tramp-archive and file-directory-p

[Michael Albinus]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Anybody else is invited to implement a native libarchive(3) integration
>> into Emacs, as I have said several times already. Should we add this on
>> etc/TODO?
>
> Makes sense to me.

Done, in the "Wishlist item" department.

Best regards, Michael.

bug#58360: 28.2; tramp-archive and file-directory-p

[Stefan Kangas]

tags 58360 notabug wontfix
close 58360
thanks

Michael Albinus <michael.albinus@gmx.de> writes:

> This is intended. There is no need for packages like counsel to check
>
> (file-directory-p (expand-file-name "~/file.odt/"))
>
> It is a misuse to add a slash to an existing regular file and pray that
> it works. There has been a similar error in ange-ftp, see bug#56078. It
> has fixed. I recommend to contact the counsel author for a fix.

So this is not something we're going to change on our end, and I'm
therefore closing this bug report.

bug#58360: 28.2; tramp-archive and file-directory-p

[Gustavo Barros]

On Sat, 08 Oct 2022 at 13:38, Michael Albinus <michael.albinus@gmx.de> 
wrote:

> Hi Gustavo,

Hi Michael,

> This is intended.

That's then cleared.  Thank you for your answer.

> There is no need for packages like counsel to check
>
> (file-directory-p (expand-file-name "~/file.odt/"))
>
> It is a misuse to add a slash to an existing regular file and pray 
> that
> it works. There has been a similar error in ange-ftp, see 
> bug#56078. It
> has fixed. I recommend to contact the counsel author for a fix.

I have done so: https://github.com/abo-abo/swiper/issues/2998

> There might be people who wish to navigate into "odt", "exe", or "deb"
> files. It shall be possible. It happens only if you access
> "/path/to/file.odt/" (the trailing slash is important), for which 
> there
> is no other desired behavior I could imagine.

Well, I'd say there's a difference between "being possible" and "being 
the default".  But I don't intend to fuss about it, as I do understand 
your point of view, particularly given the answer above.  It is a 
consistent position.  As I've said initially, I was surprised, but 
reported just to check if things were really as intended.

> I doubt that people would change such a user option. What would be the
> use case? There is still tramp-archive-enabled, and if a package 
> really
> really really wants to access "file.odt/" for another purpose than the
> intended, the package shall let-bind this variable.

I was just thinking people might want different behaviors depending on 
the file type.  But I'm sure your knowledge of use cases for the feature 
is much better than my "just got acquainted with the package" one.  So 
if you think this is of little use, I trust your call.  ;-)

> Best regards, Michael.

Best regards,
Gustavo.

bug#58360: 28.2; tramp-archive and file-directory-p

[Gustavo Barros]

On Sat, 08 Oct 2022 at 13:47, Michael Albinus <michael.albinus@gmx.de> 
wrote:

> Hi Gustavo,

Hi Michael,

> tramp-archive.el is implemented by using the archive backend of
> GVFS. This means, that the file is mounted via fuse.
>
> I wish we would have another implementation, for example integrating
> libarchive(3) directly into Emacs. This would avoid mounting, and it
> would allow us to use it on other platforms but GNU/Linux only. But
> nobody has implemented this yet.
>
> It is on my TODO under the section "When I really run out of ideas 
> what
> to do else". But this section doesn't get attention by me yet.
>
> Anybody else is invited to implement a native libarchive(3) 
> integration
> into Emacs, as I have said several times already. Should we add this 
> on
> etc/TODO?

Well, I wasn't even thinking in terms of dependencies, just the 
consideration that simply testing the predicate on the file generates 
the mount point.

Of course, native integration of libarchive would be welcome, but that 
was not what I meant to criticize.

Either way, understood, particularly considering you made clear in the 
other message that calling the predicate on a file with the appended 
slash is a "misuse", which was something I had failed to grasp when I 
wrote.

Thank you once again.

> Best regards, Michael.

Best regards,
Gustavo.