[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: testing for a remote file to include file on a Windows mappeddrive
From: |
Michael Albinus |
Subject: |
Re: testing for a remote file to include file on a Windows mappeddrive |
Date: |
Sat, 26 Jan 2008 23:15:08 +0100 |
User-agent: |
Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
>> file-remote-p returns information about the *file name*, and not
>> necessarily about the file: "Can the file name be used literally on the
>> local host?" I believe this meaning shall be kept, for example, it is
>> needed to determine whether a file name must be trimmed when used as
>> argument of process-file and alike.
>
>> The new function you are looking for is file-mounted-p or so.
>
> I believe you're wrong and I'm right ;-)
For sure. At least it has been the case almost ever when we did discuss.
> What you consider as the meaning of `file-remote-p' is pretty close to
> the info returned by (let ((file-name-handlers-alist nil)) (not
> (file-readable-p <FILE>))), whereas what you want to call
> `file-mounted-p' is much closer to what `file-remote-p' currently does.
>
> E.g. (file-remote-p "/:/") will return nil, even though passing "/:/" as
> an argument to a subprocess will likely fail to do what was intended.
>
> After all, whether the filename can be passed to a subprocess has
> nothing to do with whether or not it's "remote".
Hmm. I haven't said that the result of `file-remote-p' is the only check
how to pass a file name as argument to a subprocess. But when
`file-remote-p' returns non-nil, it means that you can't take the
related file literally as part of ARGS in 'process-file' and friends.
> I suggest we clarify the meaning of file-remote-p to explain that it
> returns info that relates to the time and reliability of the access to
> this file. And we introduce a new one `unhandled-file-name' which
> returns either "an equivalent name that can passed to subprocesses"
> (e.g. for the "/:/" file-name-handler, it just strips the leading "/:"
> and similarly for the "file://" one) or nil if the file cannot be
> directly accessed by a subprocess (either because it's only accessible
> via ssh/ftp/tar/younameit it by a file-name-handler).
At least for remote files I've introduced it silently ...
(file-remote-p "/sudo::/etc" 'localname) returns "/etc". But you are
right, `unhandled-file-name' would be more general but just for Tramp.
But we shall come back to the original request of Drew: he wants to know
whether a given file is "remote", independant of the syntax. Such
information cannot be provided by 'file-remote-p', because that function
has an important promise: "`file-remote-p' will never open a connection
on its own." (from the doc-string). It also doesn't touch a local file;
it works completely over the file name syntax. This promise is important
because of performance.
Rough idea: maybe one could use the device number, returned as last
attribute of `file-attributes', for a check whether a file has been
"mounted". I haven't seen code evaluating the device number. And I
don't know whether it is set to a useful value on W32, for example.
Just for the records, ange-ftp sets it to -1, and Tramp returns (-1 x)
with x being a unique number for different remote connections.
> Stefan
Best regards, Michael.
- RE: testing for a remote file to include file on a Windows mappeddrive, (continued)
- RE: testing for a remote file to include file on a Windows mappeddrive, Drew Adams, 2008/01/25
- Re: testing for a remote file to include file on a Windows mappeddrive, Jason Rumney, 2008/01/25
- RE: testing for a remote file to include file on a Windows mappeddrive, Drew Adams, 2008/01/25
- Re: testing for a remote file to include file on a Windows mappeddrive, Stefan Monnier, 2008/01/25
- RE: testing for a remote file to include file on a Windows mappeddrive, Drew Adams, 2008/01/26
- Re: testing for a remote file to include file on a Windows mappeddrive, Eli Zaretskii, 2008/01/26
- Re: testing for a remote file to include file on a Windows mappeddrive, Michael Albinus, 2008/01/26
- Re: testing for a remote file to include file on a Windows mappeddrive, Jason Rumney, 2008/01/26
- RE: testing for a remote file to include file on a Windows mappeddrive, Drew Adams, 2008/01/26
- Re: testing for a remote file to include file on a Windows mappeddrive, Stefan Monnier, 2008/01/26
- Re: testing for a remote file to include file on a Windows mappeddrive,
Michael Albinus <=
- Re: testing for a remote file to include file on a Windows mappeddrive, Eli Zaretskii, 2008/01/26
- Re: testing for a remote file to include file on a Windows mappeddrive, Michael Albinus, 2008/01/27
- Re: testing for a remote file to include file on a Windows mappeddrive, Eli Zaretskii, 2008/01/27
- Re: testing for a remote file to include file on a Windows mappeddrive, Andreas Schwab, 2008/01/27
- Re: testing for a remote file to include file on a Windows mappeddrive, Michael Albinus, 2008/01/27
- RE: testing for a remote file to include file on a Windows mappeddrive, Drew Adams, 2008/01/26
- Re: testing for a remote file to include file on a Windows mappeddrive, Stefan Monnier, 2008/01/27
- Re: testing for a remote file to include file on a Windows mappeddrive, Stefan Monnier, 2008/01/27
- Re: testing for a remote file to include file on a Windows mappeddrive, Michael Albinus, 2008/01/29
- Re: testing for a remote file to include file on a Windows mappeddrive, Richard Stallman, 2008/01/30