URL + efs confusion

URL + efs confusion

[Lars Magne Ingebrigtsen]

Sometimes people put local URLs into their RSS feeds, like

<img src="file:/c:/thing/foo">

This ends up as a url call like this:

(url-retrieve "file:/c:/thing/foo" #'ignore)

which ends up prompting me for my ftp password, since c:/thing/foo is
interpreted as an efs file name.

This seems not very optimal.  Could there be situations where that URL
makes sense to interpret that way?  And what about on Windows machines?

Anybody have any suggestions about on what level this should be fixed?
Gnus, shr or url?  And how?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: URL + efs confusion

[Ted Zlatanov]

On Mon, 15 Nov 2010 21:06:37 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Sometimes people put local URLs into their RSS feeds, like
LMI> <img src="file:/c:/thing/foo">

LMI> This ends up as a url call like this:

LMI> (url-retrieve "file:/c:/thing/foo" #'ignore)

LMI> which ends up prompting me for my ftp password, since c:/thing/foo is
LMI> interpreted as an efs file name.

LMI> This seems not very optimal.  Could there be situations where that URL
LMI> makes sense to interpret that way?  And what about on Windows machines?

LMI> Anybody have any suggestions about on what level this should be fixed?
LMI> Gnus, shr or url?  And how?  :-)

I think the file: prefix should cause anything following to be
interpreted as a local file.  It seems like the URL library is the one
that should open the file literally without any filename handlers.

Ted

Re: URL + efs confusion

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LMI> (url-retrieve "file:/c:/thing/foo" #'ignore)
>
> LMI> which ends up prompting me for my ftp password, since c:/thing/foo is
> LMI> interpreted as an efs file name.

I meant ange-ftp.  I mean, tramp.

> I think the file: prefix should cause anything following to be
> interpreted as a local file.  It seems like the URL library is the one
> that should open the file literally without any filename handlers.

Yes, I think that would make most sense.

Although I'm not quite sure what the right fix here is.  The `url-file'
function is talking about ange-ftp and efs and has a lot of (featurep
'xemacs) (by the way, is it OK to remove xemacs-related stuff from the
Emacs version of url?  Or is it maintained outside of Emacs, too?) and
stuff...  but here's the backtrace when I get prompted for my password:

  tramp-file-name-handler(file-directory-p "/c:/thing/foo")
  file-directory-p("/c:/thing/foo")
  url-file-build-filename([cl-struct-url "file" nil nil nil 21 "/c:/thing/foo" nil nil nil nil])
  url-file([cl-struct-url "file" nil nil nil 21 "/c:/thing/foo" nil nil nil nil] ignore (nil))
  url-retrieve-internal("file:/c:/thing/foo" ignore (nil) nil)

Are there any variables I can bind to just disable the entire
remote-file-access-thing in `url-file-build-filename'?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: URL + efs confusion

[Stefan Monnier]

>   tramp-file-name-handler(file-directory-p "/c:/thing/foo")
>   file-directory-p("/c:/thing/foo")
>   url-file-build-filename([cl-struct-url "file" nil nil nil 21 "/c:/thing/foo" nil nil nil nil])
>   url-file([cl-struct-url "file" nil nil nil 21 "/c:/thing/foo" nil nil nil nil] ignore (nil))
>   url-retrieve-internal("file:/c:/thing/foo" ignore (nil) nil)

> Are there any variables I can bind to just disable the entire
> remote-file-access-thing in `url-file-build-filename'?

No, but if you turn it into /:/c:/thing/foo, then it will override any
file-name handler.  Not sure if that would be right for .gz files.


        Stefan

Re: URL + efs confusion

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> No, but if you turn it into /:/c:/thing/foo, then it will override any
> file-name handler.

Ah, right.  Makes sense.  I've now done this.

> Not sure if that would be right for .gz files.

No, and I'm not really sure what you'd expect

(url-retrieve "file:/tmp/foo.gz" #'handler)

to do, really.  I kinda would expect to get the .gz file, not the
uncompressed file, but today I think you get the uncompressed file.
(Although I haven't actually tested this.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: URL + efs confusion

[Michael Albinus]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Although I'm not quite sure what the right fix here is.  The `url-file'
> function is talking about ange-ftp and efs and has a lot of (featurep
> 'xemacs) (by the way, is it OK to remove xemacs-related stuff from the
> Emacs version of url?  Or is it maintained outside of Emacs, too?) and
> stuff...  but here's the backtrace when I get prompted for my password:
>
>   tramp-file-name-handler(file-directory-p "/c:/thing/foo")
>   file-directory-p("/c:/thing/foo")
>   url-file-build-filename([cl-struct-url "file" nil nil nil 21
> "/c:/thing/foo" nil nil nil nil])
>   url-file([cl-struct-url "file" nil nil nil 21 "/c:/thing/foo" nil
> nil nil nil] ignore (nil))
>   url-retrieve-internal("file:/c:/thing/foo" ignore (nil) nil)

With Emacs 24.0.50 (since July) and 23.2.50 (since August) it shouldn't
happen anymore. On w32 systems, `tramp-file-name-regexp' has the value
"\\`/\\([^[/:]\\{2,\\}\\|[^/]\\{2,\\}]\\):". Note the "\\{2,\\}"
construct, which excludes volume letters.

Best regards, Michael.

Re: URL + efs confusion

[Ted Zlatanov]

On Tue, 16 Nov 2010 09:36:42 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Although I'm not quite sure what the right fix here is.  The `url-file'
>> function is talking about ange-ftp and efs and has a lot of (featurep
>> 'xemacs) (by the way, is it OK to remove xemacs-related stuff from the
>> Emacs version of url?  Or is it maintained outside of Emacs, too?) and
>> stuff...  but here's the backtrace when I get prompted for my password:
>> 
>> tramp-file-name-handler(file-directory-p "/c:/thing/foo")
>> file-directory-p("/c:/thing/foo")
>> url-file-build-filename([cl-struct-url "file" nil nil nil 21
>> "/c:/thing/foo" nil nil nil nil])
>> url-file([cl-struct-url "file" nil nil nil 21 "/c:/thing/foo" nil
>> nil nil nil] ignore (nil))
>> url-retrieve-internal("file:/c:/thing/foo" ignore (nil) nil)

MA> With Emacs 24.0.50 (since July) and 23.2.50 (since August) it shouldn't
MA> happen anymore. On w32 systems, `tramp-file-name-regexp' has the value
MA> "\\`/\\([^[/:]\\{2,\\}\\|[^/]\\{2,\\}]\\):". Note the "\\{2,\\}"
MA> construct, which excludes volume letters.

Doesn't that also exclude hosts with one-character names?  It's a rare
situation, of course...

I think it's better to handle file:/// URLs explicitly in the
url-file.el code.  They always specify a local file.  So it should only
ask for the local filename handlers in that case.  Would there be any
situation where that's not appropriate?

Ted

Re: URL + efs confusion

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think it's better to handle file:/// URLs explicitly in the
> url-file.el code.  They always specify a local file.  So it should only
> ask for the local filename handlers in that case.  Would there be any
> situation where that's not appropriate?

I can't think of any situations where somebody would knowingly create a
URL with the Emacs /foo:/-syntax.  It's possible that somebody has
created Emacs-specific HTML that uses this, but it seems rather
unlikely.  I've made the change, and we'll just see whether anybody
complains... 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: URL + efs confusion

[Davis Herring]

> I can't think of any situations where somebody would knowingly create a
> URL with the Emacs /foo:/-syntax.  It's possible that somebody has
> created Emacs-specific HTML that uses this, but it seems rather
> unlikely.

If it did, it would be incorrect to give such a URL a file: scheme,
because it's not a file name.  "/foo:/bar" ought to be emacs://foo/bar or
perhaps emacs://ftp/foo/bar (taking the access mode to be the authority; I
don't remember if you can stack access modes).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: URL + efs confusion

[David Kastrup]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> I think it's better to handle file:/// URLs explicitly in the
>> url-file.el code.  They always specify a local file.  So it should only
>> ask for the local filename handlers in that case.  Would there be any
>> situation where that's not appropriate?
>
> I can't think of any situations where somebody would knowingly create a
> URL with the Emacs /foo:/-syntax.

Something like c: suggests itself for the mountpoint of a Windows
partition or share.  In particular if you want to check for
Windows-proof file name handling.

-- 
David Kastrup

Re: URL + efs confusion

[Lars Magne Ingebrigtsen]

David Kastrup <dak@gnu.org> writes:

> Something like c: suggests itself for the mountpoint of a Windows
> partition or share.  In particular if you want to check for
> Windows-proof file name handling.

Yes, there was already a check for [a-z]: file: URLs on Windows machines
in url-file.el, and I've preserved that logic.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: URL + efs confusion

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> MA> With Emacs 24.0.50 (since July) and 23.2.50 (since August) it shouldn't
> MA> happen anymore. On w32 systems, `tramp-file-name-regexp' has the value
> MA> "\\`/\\([^[/:]\\{2,\\}\\|[^/]\\{2,\\}]\\):". Note the "\\{2,\\}"
> MA> construct, which excludes volume letters.
>
> Doesn't that also exclude hosts with one-character names?  It's a rare
> situation, of course...

Yes, it does. But unless there is a fault report, I can live with
that. Remember, we are on MS Windows. It is more than "a rare
situation", that somebody wants to access the host "/c:" ...

> Ted

Best regards, Michael.

Re: URL + efs confusion

[Ted Zlatanov]

On Tue, 16 Nov 2010 16:05:40 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
MA> With Emacs 24.0.50 (since July) and 23.2.50 (since August) it shouldn't
MA> happen anymore. On w32 systems, `tramp-file-name-regexp' has the value
MA> "\\`/\\([^[/:]\\{2,\\}\\|[^/]\\{2,\\}]\\):". Note the "\\{2,\\}"
MA> construct, which excludes volume letters.
>> 
>> Doesn't that also exclude hosts with one-character names?  It's a rare
>> situation, of course...

MA> Yes, it does. But unless there is a fault report, I can live with
MA> that. Remember, we are on MS Windows. It is more than "a rare
MA> situation", that somebody wants to access the host "/c:" ...

Oh, I'm going to name all my hosts with a single letter from now on ;)

Thanks
Ted

Re: URL + efs confusion

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> MA> Yes, it does. But unless there is a fault report, I can live with
> MA> that. Remember, we are on MS Windows. It is more than "a rare
> MA> situation", that somebody wants to access the host "/c:" ...
>
> Oh, I'm going to name all my hosts with a single letter from now on ;)

And I will reject your fault report, recommending to set environment
variable $C to "c", and to use "/$C:" as remote file name :-)

> Thanks
> Ted

Best regards, Michael.