Re: testing for a remote file to include file on a Windows mapped drive

[Michael Albinus]

Stefan Monnier <address@hidden> writes:

> I have no idea which change you're talking about.
> I just have noticed several different concerns that tend to be
> conflated:
> - reliability and performance.
> - ability to access the file via syscalls.
> - whether relative file names can be used from one file name to another.
> - whether a file's contents is directly accessible via syscalls.
>
> The first is usually/always answered by calling `file-remote-p'.

At least NOT with the current implementation. `file-remote-p' just
calls file name handlers, if any. And there seem to be only 2 such
handlers until now: `ange-ftp-file-remote-p' and
`tramp-handle-file-remote-p'.

There are also `ediff-file-remote-p' and `ffap-file-remote-p', but
they are not called from `file-remote-p'; they use this function instead.

`file-remote-p', as of today, simply answers the question, whether
there are file name handlers involved accessing a file. If it returns
non-nil, one could deduce that the access to the file might be less
reliable and less performant, but not vice-versa. And even this
interpretation was not the reason why `file-remote-p' was introduced.(*)

Maybe that is the major reason of our misunderstanding: I just read
what is implemented (yet), and I can guess only what you want to have.

I know you have adapted the docstring of `file-remote-p'. But there is
no matching implementation.

Stefan, maybe it is time to list en detail the required changes you
have in mind for this?

> The second is sometimes answered by calling file-remote-p, although it
> does not give the right answer for /:/foo, and it clashes with the
> previous use of file-remote-p if you want to say that "file://" is
> not remote.  A closer match for this is unhandled-file-name-directory,
> except that it historically didn't give useful information (it typically
> returned /tmp rather than nil for handled file names) and it only
> works for directories.

"/:" is handled in `file-name-non-special', there is no problem wrt
syscalls I believe.

"file:///foo" is a special case, indeed. I have no idea, whether the
implementation of `url-handler-mode' is complete (a year ago I've
looked at the webDAV implementation, and it wasn't ready).

If I could understand better what needs to be done for url*.el, I
would be willing to support. Is there a (prioritized) todo list what
shall be done?

> The third is currently answered by file-remote-p.  It's only used in
> file-relative-name, AFAIK, so it doesn't matter much where the info
> comes from, as long as file-relative-name is updated accordingly.
> In any case abusing file-remote-p for that seems like a bad idea.

D'accord.

> The last one is relevant for compressed files, encrypted files, and
> files extracted from tar/zip/ar/rar/... archives.  This is usually
> answered by a bunch of ad-hoc tests listing all the situations of which
> the author was aware.  E.g. it'll need update for auto-encryption-mode.
> We should introduce a new function for that.  Something like
> unhandled-file-contents.  OTOH unhandled-file-contents can only return
> non-nil if unhandled-file-name is non-nil, so maybe we should combine
> the two, and use an argument `contents' to indicate whether we only care
> about accessing the file (container) via syscalls or accessing also
> its contents.

Here I tend to agree as well.

(*): I haven't found a discussion about in the archives; Richard added
     this to files.el the same time Tramp was integrated into Emacs.

>         Stefan

Best regards, Michael.