[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 mapped drive
From: |
Stefan Monnier |
Subject: |
Re: testing for a remote file to include file on a Windows mapped drive |
Date: |
Tue, 29 Apr 2008 03:50:28 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
> I have available a checkout from April 7th. Scanning lisp/*, there are
> 40 places file-remote-p is called. Let's not regard the 17 calls of
> tramp*.el, they could be replaced simply by another, Tramp internal,
> function.
> From the other 23 calls, I would count 5 calls related to the question
> "Is the access slow"; the other calls are due to the file name handler
> thingies, which require another implementation of the respective
> functionality.
Looking at it again, I see that it is a bit less uniform than
I remembered, indeed.
> And, if you say that the calls of file-remote-p shall be replaced by
> something else, which is closer to the file name handler
> functionality: which function do you have in mind? Back in February,
> you've spoken about file-local-name/unhandled-file-name. These
> functions don't exist (yet).
> Stefan, honestly: I don't understand why file-remote-p needs such a
> redefinition. I assume there is a plan behind, which we don't know.
> It would really be helpful if we could understand your intention of
> this change.
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'.
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.
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.
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.
> One explanation, also in February, was that you want to have
> (file-remote-p "file:///toto/titi") => nil
> But with the same reasoning, you could say
> (file-remote-p "/sudo:address@hidden:/toto/titi") => nil
> And that doesn't work, IMHO.
I don't have a strong opinion on "/sudo:address@hidden:/toto/titi":
I think it would be OK to return nil, but non-nil is OK as well: access
via sudo is probably slower and may even require user-input.
I'm not sure why you say it wouldn't work to return nil for it.
Stefan
- Re: testing for a remote file to include file on a Windows mapped drive, (continued)
- Re: testing for a remote file to include file on a Windows mapped drive, Eli Zaretskii, 2008/04/21
- Re: testing for a remote file to include file on a Windows mapped drive, Stefan Monnier, 2008/04/21
- Re: testing for a remote file to include file on a Windows mapped drive, Eli Zaretskii, 2008/04/21
- Re: testing for a remote file to include file on a Windows mapped drive, Stefan Monnier, 2008/04/22
- Re: testing for a remote file to include file on a Windows mapped drive, Eli Zaretskii, 2008/04/22
- Re: testing for a remote file to include file on a Windows mapped drive, Michael Albinus, 2008/04/22
- Re: testing for a remote file to include file on a Windows mapped drive,
Stefan Monnier <=
- Re: testing for a remote file to include file on a Windows mapped drive, Eli Zaretskii, 2008/04/29
- Re: testing for a remote file to include file on a Windows mapped drive, Stefan Monnier, 2008/04/29
- Re: testing for a remote file to include file on a Windows mapped drive, Eli Zaretskii, 2008/04/29
- Re: testing for a remote file to include file on a Windows mapped drive, Stefan Monnier, 2008/04/30
- RE: testing for a remote file to include file on a Windows mapped drive, Drew Adams, 2008/04/30
- Re: testing for a remote file to include file on a Windows mapped drive, Stefan Monnier, 2008/04/30
- RE: testing for a remote file to include file on a Windows mapped drive, Drew Adams, 2008/04/30
- Re: testing for a remote file to include file on a Windows mapped drive, Eli Zaretskii, 2008/04/21
- Re: testing for a remote file to include file on a Windows mapped drive, Michael Albinus, 2008/04/22