Re: testing for a remote file to include file on a Windows mappeddrive

[Michael Albinus]

Stefan Monnier <address@hidden> writes:

>> There might be cases where this is still not sufficient. Think about a
>> Samba server, which offers several "shares" one cannot simply navigate
>> via `file-relative-name'. But given that the "smb" method of Tramp
>> does not support `process-file' and `start-file-process' (yet?), it
>> might be a good approximation to check for `file-name-absolute-p'.
>
> I don't understand what you're trying to say.

Just that your proposal (use file-relative-name for trimming arguments
of remote subprocesses) works only, if the remote side has a UNIX-like
filesystem with a unique root "/". Given, that remote subprocesses are
implemented today just for such types of remote hosts, it is a
sufficient assumption.

>> If I've checked correctly, only ange-ftp.el, tramp.el and
>> url-handlers.el offer an own implementation of
>> `unhandled-file-name-directory'.  It might not be necessary to
>> delegate the implementation to those packages; the case of
>> "remoteness" could be handled directly in
>> Funhandled_file_name_directory.
>
> And I do not understand what implementation of
> Funhandled_file_name_directory you have in mind.

I wanted to say that unhandled-file-name-directory does not need a file
name handler. But ...

>   (unhandled-file-name-directory "file:///toto/titi") -> "/toto"

... convinces me that I'm wrong. Achhh.

>> Just being curious: url-handlers.el misses an own implementation of
>> `file-remote-p'; shouldn't it be there?
>
> Yes, it should.  Patches welcome ;-)

I'll do so. But it raises the question: Is "file:///toto/titi" remote? I
would say no, but it depends how file-remote-p is used. If it is applied
in tests like "Can I use the filename literally for local purposes",
then (file-remote-p" file:///toto/titi") must return a non-nil value.

>         Stefan

Best regards, Michael.