Function to know weither a dir is local or remote

Function to know weither a dir is local or remote

[Pascal Quesseveur]

Hello,

I wanted to know if there is a function to know weither a file path
denotes a local or a remote file.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Function to know weither a dir is local or remote

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Thu, 20 Oct 2022 08:45:39 +0200
> 
> I wanted to know if there is a function to know weither a file path
> denotes a local or a remote file.

Is file-remote-p what you want?

Re: Function to know weither a dir is local or remote

[Jean Louis]

* Pascal Quesseveur <pquessev@gmail.com> [2022-10-20 10:04]:
> Hello,
> 
> I wanted to know if there is a function to know weither a file path
> denotes a local or a remote file.

file-remote-p is a byte-compiled Lisp function in ‘files.el’.

(file-remote-p FILE &optional IDENTIFICATION CONNECTED)

Test whether FILE specifies a location on a remote system.
A file is considered remote if accessing it is likely to
be slower or less reliable than accessing local files.

‘file-remote-p’ never opens a new remote connection.  It can
reuse only a connection that is already open.

Return nil or a string identifying the remote connection
(ideally a prefix of FILE).  Return nil if FILE is a relative
file name.

When IDENTIFICATION is nil, the returned string is a complete
remote identifier: with components method, user, and host.  The
components are those present in FILE, with defaults filled in for
any that are missing.

IDENTIFICATION can specify which part of the identification to
return.  IDENTIFICATION can be the symbol ‘method’, ‘user’,
‘host’, or ‘localname’.  Any other value is handled like nil and
means to return the complete identification.  The string returned
for IDENTIFICATION ‘localname’ can differ depending on whether
there is an existing connection.

If CONNECTED is non-nil, return an identification only if FILE is
located on a remote system and a connection is established to
that remote system.

Tip: You can use this expansion of remote identifier components
     to derive a new remote file name from an existing one.  For
     example, if FILE is "/sudo::/path/to/file" then

       (concat (file-remote-p FILE) "/bin/sh")

     returns a remote file name for file "/bin/sh" that has the
     same remote identifier as FILE but expanded; a name such as
     "/sudo:root@myhost:/bin/sh".

  Other relevant functions are documented in the file group.
  Probably introduced at or before Emacs version 22.1.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Function to know weither a dir is local or remote

[Pascal Quesseveur]

>"JL" == Jean Louis <bugs@gnu.support> writes:

  JL> file-remote-p is a byte-compiled Lisp function in ‘files.el’.

I should have sayed I had looked at file-remote-p. FMU it works only
when there is a file handler defined for file-remote-p operation. I
have checked different paths on my system and it always returns
nil. Maybe I am not using it correctly.

I was looking for a function that could work with a general path
(resolved with file-truename).


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Function to know weither a dir is local or remote

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Thu, 20 Oct 2022 10:13:25 +0200
> 
> >"JL" == Jean Louis <bugs@gnu.support> writes:
> 
>   JL> file-remote-p is a byte-compiled Lisp function in ‘files.el’.
> 
> I should have sayed I had looked at file-remote-p. FMU it works only
> when there is a file handler defined for file-remote-p operation.

Yes, but the handler should be installed automatically and by default.

> I have checked different paths on my system and it always returns
> nil. Maybe I am not using it correctly.

Please show a recipe starting from "emacs -Q" where file-remote-p
doesn't work as advertised.

Re: Function to know weither a dir is local or remote

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> Please show a recipe starting from "emacs -Q" where
  EZ> file-remote-p doesn't work as advertised.

emacs 28.1 on Windows:

(file-remote-p "C:/Users/Public/Applis/appli") -> nil
(file-truename "C:/Users/Public/Applis/appli") -> //server/applis/appli
(file-remote-p (file-truename "C:/Users/Public/Applis/appli")) -> nil


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Function to know weither a dir is local or remote

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Thu, 20 Oct 2022 11:35:14 +0200
> 
> >"EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
>   EZ> Please show a recipe starting from "emacs -Q" where
>   EZ> file-remote-p doesn't work as advertised.
> 
> emacs 28.1 on Windows:
> 
> (file-remote-p "C:/Users/Public/Applis/appli") -> nil
> (file-truename "C:/Users/Public/Applis/appli") -> //server/applis/appli
> (file-remote-p (file-truename "C:/Users/Public/Applis/appli")) -> nil

These aren't remote file names.  Why did you expect file-remote-p to
return non-nil for a UNC?  A UNC doesn't have to be on a remote
computer.

What is the specific problem for which you needed to distinguish
between a file shared by another computer and a file on a local drive?

Re: Function to know weither a dir is local or remote

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> These aren't remote file names.

I am not sure what a remote file name is. There is nothing in
file-remote-p documentation which explains what a remote file name is.

  EZ> A UNC doesn't have to be on a remote computer.

Yes, I know. But in this case it is a remote path.
  
  EZ> What is the specific problem for which you needed to distinguish
  EZ> between a file shared by another computer and a file on a local
  EZ> drive?

My problem is the following. In Org there is a function to create a
PDF from an org file. That function displays an error message when a
problem occured during PDF creation. To find out if a problem occured
during creation, that function compares the time at the beginning of
the processing and the last modification time of the PDF file. When
the later is behind the former, the function displays an error
message. The problem is when the directory of the PDF file is on a
server, server current time can be different from client current time,
and then the error can be wrongly displayed.

One solution to correct the function can be to create a temporary file
in the same directory as the PDF file and compare the times using
creation time of the temporary file instead of local current time. So
I wanted to know if there exists a function that can check a path and
tells if its remote or local.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Function to know weither a dir is local or remote

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Thu, 20 Oct 2022 14:54:40 +0200
> 
> My problem is the following. In Org there is a function to create a
> PDF from an org file. That function displays an error message when a
> problem occured during PDF creation. To find out if a problem occured
> during creation, that function compares the time at the beginning of
> the processing and the last modification time of the PDF file. When
> the later is behind the former, the function displays an error
> message. The problem is when the directory of the PDF file is on a
> server, server current time can be different from client current time,
> and then the error can be wrongly displayed.

This problem is not specific to MS-Windows, it is something that Org
should handle on every system.  So my first advice is to ask the Org
developers how they propose to fix this problem.  The reliance on
synchronized time stamp sounds flaky to me.

> One solution to correct the function can be to create a temporary file
> in the same directory as the PDF file and compare the times using
> creation time of the temporary file instead of local current time. So
> I wanted to know if there exists a function that can check a path and
> tells if its remote or local.

We don't have such a function, no.  You could perhaps approximate it
by assuming that every UNC is a remote file.

Re: Function to know weither a dir is local or remote

[Michael Albinus]

Pascal Quesseveur <pquessev@gmail.com> writes:

>   EZ> These aren't remote file names.
>
> I am not sure what a remote file name is. There is nothing in
> file-remote-p documentation which explains what a remote file name is.

(info "(emacs) Remote Files")

Best regards, Michael.

Re: Function to know weither a dir is local or remote

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> This problem is not specific to MS-Windows, it is something that
  EZ> Org should handle on every system.

Yes, I never said it was specific to MS-Windows.

  EZ> So my first advice is to ask the Org developers how they propose
  EZ> to fix this problem.  The reliance on synchronized time stamp
  EZ> sounds flaky to me.

I did that. I was trying to find a solution to improve the function.

  EZ> We don't have such a function, no.

file-remote-p works only when you use a special file name syntax. This
is not clear from the docstring.

  EZ> You could perhaps approximate it by assuming that every UNC is a
  EZ> remote file.

But as you said every UNC is not a remote file.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Function to know weither a dir is local or remote

[Pascal Quesseveur]

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

  MA> (info "(emacs) Remote Files")

Thanks


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Function to know weither a dir is local or remote

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Fri, 21 Oct 2022 09:46:47 +0200
> 
> file-remote-p works only when you use a special file name syntax. This
> is not clear from the docstring.

Almost all file-* functions operate just on the syntax.  But feel free
to submit a documentation bug report about clarifying this aspect.

> 
>   EZ> You could perhaps approximate it by assuming that every UNC is a
>   EZ> remote file.
> 
> But as you said every UNC is not a remote file.

Yes.  Thus the "approximate" part.

Re: Function to know weither a dir is local or remote

[tomas]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Fri, Oct 21, 2022 at 09:46:47AM +0200, Pascal Quesseveur wrote:

[...]

> file-remote-p works only when you use a special file name syntax. This
> is not clear from the docstring.

I think it's not about the syntax per se, but about whether Emacs handles
the remoteness itself or it is the operating system's job.

In the second case (e.g. an NFS mount or something similar) I don't know
whether there is a systematic way for Emacs to know.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Function to know weither a dir is local or remote

[Stefan Monnier via Users list for the GNU Emacs text editor]

tomas@tuxteam.de [2022-10-21 19:00:56] wrote:
>> file-remote-p works only when you use a special file name syntax. This
>> is not clear from the docstring.
> I think it's not about the syntax per se, but about whether Emacs handles
> the remoteness itself or it is the operating system's job.

There's also the question of it means to be "remote".
Is a file accessed via /su:... remote?
What about a file accessed via NFS to a virtual machine running on the
same physical machine?


        Stefan

Re: Function to know weither a dir is local or remote

[tomas]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

On Tue, Oct 25, 2022 at 01:01:14PM -0400, Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> tomas@tuxteam.de [2022-10-21 19:00:56] wrote:
> >> file-remote-p works only when you use a special file name syntax. This
> >> is not clear from the docstring.
> > I think it's not about the syntax per se, but about whether Emacs handles
> > the remoteness itself or it is the operating system's job.
> 
> There's also the question of it means to be "remote".
> Is a file accessed via /su:... remote?
> What about a file accessed via NFS to a virtual machine running on the
> same physical machine?

Definitely. The closer you look at it the more elusive the thing
becomes :)

For the OP, I think the takeaway is that file-remote-p can only be
about remoteness Emacs "knows about", i.e. where Emacs handles the
protocol "bringing over" the file. So no NFS, no CIFS etc.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Function to know weither a dir is local or remote

[Pascal Quesseveur]

>"T" ==   <tomas@tuxteam.de> writes:

  T> For the OP, I think the takeaway is that file-remote-p can only
  T> be about remoteness Emacs "knows about", i.e. where Emacs handles
  T> the protocol "bringing over" the file. So no NFS, no CIFS etc.

As I said it was not clear for me from the doc. For all the reasons
mentioned I didn't think it was possible that such a function existed
but I wanted to make sure.

Thanks.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: Function to know weither a dir is local or remote

[Michael Albinus]

Pascal Quesseveur <pquessev@gmail.com> writes:

Hi,

> As I said it was not clear for me from the doc. For all the reasons
> mentioned I didn't think it was possible that such a function existed
> but I wanted to make sure.

For mounted file systems we have the variable `mounted-file-systems'
which could be used for checks. It is a heuristic based on the local
file name, 'tho.

See function `temporary-file-directory' which uses it.

> Thanks.

Best regards, Michael.

Re: Function to know weither a dir is local or remote

[Pascal Quesseveur]

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

  MA> For mounted file systems we have the variable `mounted-file-systems'
  MA> which could be used for checks. It is a heuristic based on the local
  MA> file name, 'tho.

I did not know this variable. Actually it could work. In my case
file-truename is of the form //server/dir, and on Windows
mounted-file-systems matches that string.

But anyway the problem was solved without the need for that function.

Thanks,


-- 
Pascal Quesseveur
pquessev@gmail.com