[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#68976: 30.0.50; Tramp: unexpected error when calling (file-remote-p
From: |
Eli Zaretskii |
Subject: |
bug#68976: 30.0.50; Tramp: unexpected error when calling (file-remote-p "/dav:localhost#8000:/foo") |
Date: |
Wed, 07 Feb 2024 18:29:15 +0200 |
> Cc: michael.albinus@gmx.de
> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Wed, 07 Feb 2024 16:08:20 +0000
>
> Today, I tried to execute an innocent test checking if a file is remote
> or not:
>
> (file-remote-p "/dav:localhost#8000:/foo")
>
> Unexpectedly, I encountered user error
> tramp-error: Package `tramp-gvfs' not supported
>
> I did not expect that `file-remote-p' should ever throw an error other
> than when passed non-string argument.
>
> Looking at the code, (setq tramp-gvfs-enabled t) would make the error
> disappear. (The default value is nil)
>
> I believe that it is inappropriate that throw an error in such
> situation. If "gvfs" is not supported, but still claimed to be remote by
> TRAMP, I expect non-nil return value when calling `file-remote-p'; not
> an error.
What if the "dav:" part was deliberate, i.e. not an accident? That
ism the caller did want to access a gvfs remote filesystem. Returning
nil in that case would be exactly the wrong thing to do. IOW, please
keep in mind that file-remote-p is called internally by many APIs, and
its main use case is to be called at such a low level, where silently
failing is not an option.
So I'm not sure we want to fix this, but maybe Michael will suggest
some solution.