bug#5345: Password asked when visiting a file in a lightweight checkout

bug#5345: Password asked when visiting a file in a lightweight checkout

[Juanma Barranquero]

With an up-to-date trunk build.

  emacs -Q
  C-x C-f C:/emacs/repo/test-lightweight/etc/NEWS <RET>
  => "Password for Juanma@C:"     -- Juanma being my user-name
  C-g
  C-x C-f C:/emacs/repo/test-lightweight/etc/NEWS <RET>
  => the file is visited OK.

It's happening for all files in lightweight checkouts:

  C:\emacs\repo\test-lightweight> bzr info
  Lightweight checkout (format: 2a or development-subtree)
  Location:
         light checkout root: .
    repository checkout root: C:/emacs/repo/trunk
          checkout of branch: sftp://bzr.savannah.gnu.org/srv/bzr/emacs/trunk/
           shared repository: C:/emacs/repo

  Related branches:
    public branch: sftp://bzr.savannah.gnu.org/srv/bzr/emacs/trunk
    parent branch: sftp://bzr.savannah.gnu.org/srv/bzr/emacs/trunk/

It does not happen for heavyweight checkouts, bound branches, or
normal (non-bound, non-checkout) branches.

    Juanma

bug#5345: Password asked when visiting a file in a lightweight checkout

[Michael Albinus]

Juanma Barranquero <lekktu@gmail.com> writes:

> With an up-to-date trunk build.
>
>   emacs -Q
>   C-x C-f C:/emacs/repo/test-lightweight/etc/NEWS <RET>
>   => "Password for Juanma@C:"     -- Juanma being my user-name
>   C-g
>   C-x C-f C:/emacs/repo/test-lightweight/etc/NEWS <RET>
>   => the file is visited OK.

Could you, please, set `debug-on-quit' to t? Then the backtrace after
C-g might be interesting.

>     Juanma

Best regards, Michael.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Juanma Barranquero]

On Sat, Jan 9, 2010 at 11:11, Michael Albinus <michael.albinus@gmx.de> wrote:

> Could you, please, set `debug-on-quit' to t? Then the backtrace after
> C-g might be interesting.

Yes, of course.

The backtrace corresponds to find-file etc/NEWS in branch
C:/emacs/repo/test-lightweight, which is a lightweight checkout of
C:/emacs/repo/trunk.

    Juanma



Debugger entered--Lisp error: (quit)
  byte-code("\301^P\302\303!\207" [quit-flag t eval (ignore nil)] 2)
  read-passwd("Password for Juanma@C: ")
  ange-ftp-get-passwd("C" "Juanma")
  ange-ftp-get-process("C" "Juanma")
  ange-ftp-host-type("C" "Juanma")
  ange-ftp-ls("/C:/emacs/repo/trunk/.bzr/branch/format/" "-al" t t)
  ange-ftp-get-files("/C:/emacs/repo/trunk/.bzr/branch/format" t)
  ange-ftp-file-entry-p("/C:/emacs/repo/trunk/.bzr/branch/format")
  ange-ftp-file-exists-p("/C:/emacs/repo/trunk/.bzr/branch/format")
  apply(ange-ftp-file-exists-p "/C:/emacs/repo/trunk/.bzr/branch/format")
  byte-code("\304^X\305 ^Y\306\216\307\n^K\"+\207" [debug-on-error
save-match-data-internal fn args t match-data ((byte-code
"\301^H\302\"\207" [save-match-data-internal set-match-data evaporate]
3)) apply] 3)
  ange-ftp-hook-function(file-exists-p
"/C:/emacs/repo/trunk/.bzr/branch/format")
  apply(ange-ftp-hook-function file-exists-p
"/C:/emacs/repo/trunk/.bzr/branch/format")
  tramp-ftp-file-name-handler(file-exists-p
"/C:/emacs/repo/trunk/.bzr/branch/format")
  apply(tramp-ftp-file-name-handler file-exists-p
"/C:/emacs/repo/trunk/.bzr/branch/format")
  tramp-file-name-handler(file-exists-p
"/C:/emacs/repo/trunk/.bzr/branch/format")
  file-exists-p("/C:/emacs/repo/trunk/.bzr/branch/format")
  vc-bzr-working-revision("c:/emacs/repo/test-lightweight/etc/NEWS")
  apply(vc-bzr-working-revision "c:/emacs/repo/test-lightweight/etc/NEWS")
  vc-call-backend(Bzr working-revision
"c:/emacs/repo/test-lightweight/etc/NEWS")
  vc-working-revision("c:/emacs/repo/test-lightweight/etc/NEWS" Bzr)
  vc-default-mode-line-string(Bzr "c:/emacs/repo/test-lightweight/etc/NEWS")
  apply(vc-default-mode-line-string Bzr
"c:/emacs/repo/test-lightweight/etc/NEWS")
  vc-call-backend(Bzr mode-line-string
"c:/emacs/repo/test-lightweight/etc/NEWS")
  vc-mode-line("c:/emacs/repo/test-lightweight/etc/NEWS" Bzr)
  vc-find-file-hook()
  run-hooks(find-file-hook)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer NEWS>
"c:/emacs/repo/test-lightweight/etc/NEWS" nil nil
"c:/emacs/repo/test-lightweight/etc/NEWS" ((3072 4 . 28960) (10917 .
23791)))
  find-file-noselect("c:/emacs/repo/test-lightweight/etc/NEWS" nil nil t)
  find-file("c:/emacs/repo/test-lightweight/etc/NEWS" t)
  call-interactively(find-file nil nil)

bug#5345: Password asked when visiting a file in a lightweight checkout

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 9 Jan 2010 13:44:02 +0100
> Cc: 5345@debbugs.gnu.org
> 
>   file-exists-p("/C:/emacs/repo/trunk/.bzr/branch/format")  <<<<<<<<<<
>   vc-bzr-working-revision("c:/emacs/repo/test-lightweight/etc/NEWS")
>   apply(vc-bzr-working-revision "c:/emacs/repo/test-lightweight/etc/NEWS")
>   vc-call-backend(Bzr working-revision "c:/emacs/repo/test-lightweight/etc/NEWS")

Here's the bug: some code thinks that "C:/foo" is not an absolute file
name, probably because it checks for the leading slash.  So it
prepends a slash, which alters the semantics of the file to be a
remote file on a mythical machine called "C", with predictable
results.

I'd take a good look at vc-bzr-working-revision and the subroutines it
calls.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Juanma Barranquero]

On Sat, Jan 9, 2010 at 14:52, Eli Zaretskii <eliz@gnu.org> wrote:

> Here's the bug:

You're right.

> some code thinks that "C:/foo" is not an absolute file
> name, probably because it checks for the leading slash.

In fact, what happens is that a regular expression is removing the
initial file:// from a file: URI, and not taking into account that it
could start with a triple-slash. Or it *is* taking it into account and
doing it on purpose to get a /path on Unix.

If removing three slashes is OK, the patch is as easy as changing
"file://\\(.+\\)" to "file:///?\\(.+\\)". If not, a check for windows
(or for a Windows-style path) will have to be done.

Dan, comments?

   Juanma

bug#5345: Password asked when visiting a file in a lightweight checkout

[Dan Nicolaescu]

Juanma Barranquero <lekktu@gmail.com> writes:

  > On Sat, Jan 9, 2010 at 14:52, Eli Zaretskii <eliz@gnu.org> wrote:
  > 
  > > Here's the bug:
  > 
  > You're right.
  > 
  > > some code thinks that "C:/foo" is not an absolute file
  > > name, probably because it checks for the leading slash.
  > 
  > In fact, what happens is that a regular expression is removing the
  > initial file:// from a file: URI, and not taking into account that it
  > could start with a triple-slash. Or it *is* taking it into account and
  > doing it on purpose to get a /path on Unix.
  > 
  > If removing three slashes is OK, the patch is as easy as changing

The third slash is part of the absolute file name, so it needs to stay.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Michael Albinus]

Juanma Barranquero <lekktu@gmail.com> writes:

>   tramp-file-name-handler(file-exists-p
> "/C:/emacs/repo/trunk/.bzr/branch/format")
>   file-exists-p("/C:/emacs/repo/trunk/.bzr/branch/format")
>   vc-bzr-working-revision("c:/emacs/repo/test-lightweight/etc/NEWS")

Adding a leading "/" to "C:/emacs/repo/trunk/.bzr/branch/format" in
`vc-bzr-working-revision' seems to be the culprit.

Best regards, Michael.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Juanma Barranquero]

On Sat, Jan 9, 2010 at 19:46, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> The third slash is part of the absolute file name

Not for Windows file:// URIs. For example, in one of my lightweight
checkouts, .bzr/branch/location contains:

  file:///C:/emacs/repo/bugs/5313/

> so it needs to stay.

OK, then we must also check whether the absolute filename is
Windows-style, i.e. ^/?[A-Z]:.*$ (assuming the unwanted first slash).
Do you want to fix it?

    Juanma

bug#5345: Password asked when visiting a file in a lightweight checkout

[Dan Nicolaescu]

Juanma Barranquero <lekktu@gmail.com> writes:

  > On Sat, Jan 9, 2010 at 19:46, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > The third slash is part of the absolute file name
  > 
  > Not for Windows file:// URIs. For example, in one of my lightweight

I meant for unix-like systems.

  > checkouts, .bzr/branch/location contains:
  > 
  >   file:///C:/emacs/repo/bugs/5313/

Is that the correct URL syntax?  If not, they please let the bzr people
know about it.

  > > so it needs to stay.
  > 
  > OK, then we must also check whether the absolute filename is
  > Windows-style, i.e. ^/?[A-Z]:.*$ (assuming the unwanted first slash).
  > Do you want to fix it?

No.  I can't test it.
But please do it with a system-type test, /C:/emacs/repo/bugs/5313/ is a
valid unix file name.  Probably not used too much, but valid, so it
should not be excluded.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Juanma Barranquero]

On Sat, Jan 9, 2010 at 20:20, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Is that the correct URL syntax?

Yes. This kind of URL is very common when dealing with files on
Windows. According to RFC 1738 ("Uniform Resource Locators (URL)"),
section 3.10 ("FILES"), the syntax is

     file://<host>/<path>

i.e., the slashes are separators. And "[a]s a special case, <host> can
be the string "localhost" or the empty string; this is interpreted as
`the machine from which the URL is being interpreted'.". So
file:///C:/path is a perfectly valid URL for a local file on Windows,
as a shorthand for file://localhost/C:/path. I'm surprised Unix URLs
for absolute paths do not start with file:////.

> But please do it with a system-type test, /C:/emacs/repo/bugs/5313/ is a
> valid unix file name.  Probably not used too much, but valid, so it
> should not be excluded.

Are you OK with the following patch?

    Juanma


=== modified file 'lisp/vc-bzr.el'
--- lisp/vc-bzr.el	2010-01-06 15:11:52 +0000
+++ lisp/vc-bzr.el	2010-01-09 20:06:10 +0000
@@ -361,6 +361,11 @@
 		     ;; look there for the version information.
 		     (when (re-search-forward "file://\\(.+\\)" nil t)
 		       (let ((l-c-parent-dir (match-string 1)))
+			 (when (and (memq system-type '(ms-dos windows-nt))
+				    (string-match-p "^/[[:alpha:]]:" l-c-parent-dir))
+			   ;;; On Windows, file:// URLs often have three slashes,
+			   ;;; so we must remove the remaining one (bug#5345)
+			   (setq l-c-parent-dir (substring l-c-parent-dir 1)))
 			 (setq branch-format-file
 			       (expand-file-name vc-bzr-admin-branch-format-file
 						 l-c-parent-dir))

bug#5345: Password asked when visiting a file in a lightweight checkout

[Dan Nicolaescu]

Juanma Barranquero <lekktu@gmail.com> writes:

  > On Sat, Jan 9, 2010 at 20:20, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > Is that the correct URL syntax?
  > 
  > Yes. This kind of URL is very common when dealing with files on
  > Windows. According to RFC 1738 ("Uniform Resource Locators (URL)"),
  > section 3.10 ("FILES"), the syntax is
  > 
  >      file://<host>/<path>
  > 
  > i.e., the slashes are separators. And "[a]s a special case, <host> can
  > be the string "localhost" or the empty string; this is interpreted as
  > `the machine from which the URL is being interpreted'.". So
  > file:///C:/path is a perfectly valid URL for a local file on Windows,
  > as a shorthand for file://localhost/C:/path. I'm surprised Unix URLs
  > for absolute paths do not start with file:////.
  > 
  > > But please do it with a system-type test, /C:/emacs/repo/bugs/5313/ is a
  > > valid unix file name.  Probably not used too much, but valid, so it
  > > should not be excluded.
  > 
  > Are you OK with the following patch?

Sure.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Lennart Borgman]

On Sat, Jan 9, 2010 at 9:39 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> Juanma Barranquero <lekktu@gmail.com> writes:
>
>  > On Sat, Jan 9, 2010 at 20:20, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>  >
>  > > Is that the correct URL syntax?
>  >
>  > Yes. This kind of URL is very common when dealing with files on
>  > Windows. According to RFC 1738 ("Uniform Resource Locators (URL)"),
>  > section 3.10 ("FILES"), the syntax is
>  >
>  >      file://<host>/<path>
>  >
>  > i.e., the slashes are separators. And "[a]s a special case, <host> can
>  > be the string "localhost" or the empty string; this is interpreted as
>  > `the machine from which the URL is being interpreted'.". So
>  > file:///C:/path is a perfectly valid URL for a local file on Windows,
>  > as a shorthand for file://localhost/C:/path. I'm surprised Unix URLs
>  > for absolute paths do not start with file:////.


We were discussing before if file://c:/some/where.txt also was
correct. We could not rule out the possibility that it was. So please
take care of this case too.


>  > > But please do it with a system-type test, /C:/emacs/repo/bugs/5313/ is a
>  > > valid unix file name.  Probably not used too much, but valid, so it
>  > > should not be excluded.
>  >
>  > Are you OK with the following patch?
>
> Sure.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Juanma Barranquero]

On Sat, Jan 9, 2010 at 21:57, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> We were discussing before if file://c:/some/where.txt also was
> correct. We could not rule out the possibility that it was.

I don't think it is. RFC 1378 allows file://host/path, and some other
RFC (don't remember the #) apparently allows file:/path, but that
wouldn't grok file://c:/my/path (though it could grok file://my/path,
if the drive is omitted).

> So please take care of this case too.

It's already taken care of. Look at the patch.

    Juanma

bug#5345: marked as done (Password asked when visiting a file in a lightweight checkout)

[Emacs bug Tracking System]

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

Your message dated Sat, 9 Jan 2010 22:08:04 +0100
with message-id <f7ccd24b1001091308y34abf466j1424a588134a83e6@mail.gmail.com>
and subject line Re: bug#5345: Password asked when visiting a file in a lightweight  checkout
has caused the Emacs bug report #5345,
regarding Password asked when visiting a file in a lightweight checkout
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact bug-gnu-emacs@gnu.org
immediately.)


-- 
5345: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5345
Emacs Bug Tracking System
Contact bug-gnu-emacs@gnu.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 5249 bytes --]

From: Juanma Barranquero <lekktu@gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs@gnu.org>
Subject: Password asked when visiting a file in a lightweight checkout
Date: Sat, 9 Jan 2010 03:41:28 +0100
Message-ID: <f7ccd24b1001081841t39f174ect975e4775bee8ee33@mail.gmail.com>

With an up-to-date trunk build.

  emacs -Q
  C-x C-f C:/emacs/repo/test-lightweight/etc/NEWS <RET>
  => "Password for Juanma@C:"     -- Juanma being my user-name
  C-g
  C-x C-f C:/emacs/repo/test-lightweight/etc/NEWS <RET>
  => the file is visited OK.

It's happening for all files in lightweight checkouts:

  C:\emacs\repo\test-lightweight> bzr info
  Lightweight checkout (format: 2a or development-subtree)
  Location:
         light checkout root: .
    repository checkout root: C:/emacs/repo/trunk
          checkout of branch: sftp://bzr.savannah.gnu.org/srv/bzr/emacs/trunk/
           shared repository: C:/emacs/repo

  Related branches:
    public branch: sftp://bzr.savannah.gnu.org/srv/bzr/emacs/trunk
    parent branch: sftp://bzr.savannah.gnu.org/srv/bzr/emacs/trunk/

It does not happen for heavyweight checkouts, bound branches, or
normal (non-bound, non-checkout) branches.

    Juanma




[-- Attachment #3: Type: message/rfc822, Size: 3269 bytes --]

From: Juanma Barranquero <lekktu@gmail.com>
To: 5345-done@debbugs.gnu.org
Subject: Re: bug#5345: Password asked when visiting a file in a lightweight  checkout
Date: Sat, 9 Jan 2010 22:08:04 +0100
Message-ID: <f7ccd24b1001091308y34abf466j1424a588134a83e6@mail.gmail.com>

Patch installed.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Lennart Borgman]

On Sat, Jan 9, 2010 at 10:04 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Sat, Jan 9, 2010 at 21:57, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
>> We were discussing before if file://c:/some/where.txt also was
>> correct. We could not rule out the possibility that it was.
>
> I don't think it is. RFC 1378 allows file://host/path, and some other
> RFC (don't remember the #) apparently allows file:/path,


I am surprised, but I do not remember the details any more.


> but that
> wouldn't grok file://c:/my/path


... on un*x? ... ;-)

Maybe this is where the confusion comes from (but the spec seemed
unclear to me).


(though it could grok file://my/path,
> if the drive is omitted).
>
>> So please take care of this case too.
>
> It's already taken care of. Look at the patch.


Thanks.


>    Juanma
>

bug#5345: Password asked when visiting a file in a lightweight checkout

[Michael Albinus]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> But please do it with a system-type test, /C:/emacs/repo/bugs/5313/ is a
> valid unix file name.  Probably not used too much, but valid, so it
> should not be excluded.

Emacs would handle it as a remote file name. If such a local file name
is intended, it must be prefixed by "/:". Maybe it is a good idea to do
it for all URLs starting with "file:///" in vc-bzr (and somewhere else).

Best regards, Michael.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Dan Nicolaescu]

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

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > But please do it with a system-type test, /C:/emacs/repo/bugs/5313/ is a
  > > valid unix file name.  Probably not used too much, but valid, so it
  > > should not be excluded.
  > 
  > Emacs would handle it as a remote file name. If such a local file name
  > is intended, it must be prefixed by "/:". Maybe it is a good idea to do
  > it for all URLs starting with "file:///" in vc-bzr (and somewhere else).

Can handling as a remote file name be disabled?
The code path in question makes sense when the file is local, if the
file is remote, then just running the corresponding bzr command won't
make a difference.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Michael Albinus]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Can handling as a remote file name be disabled?
> The code path in question makes sense when the file is local, if the
> file is remote, then just running the corresponding bzr command won't
> make a difference.

Adding "/:" at the top of the file name is one way. Another (maybe more
common) is let-binding `file-name-handler-alist' to nil.

OTOH, it might be that vc-bzr is handling a remote file. Directory names
found in (remote) control files must be regarded remote as well. If they
are just being used as arguments of processes, there is no problem. But
if they are used in (for example) `file-exists-p', the file name must be
extended by the remote component.

Best regards, Michael.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Reiner Steib]

On Sat, Jan 09 2010, Juanma Barranquero wrote:

> According to RFC 1738 ("Uniform Resource Locators (URL)"),
> section 3.10 ("FILES"), the syntax is
>
>      file://<host>/<path>
>
> i.e., the slashes are separators. And "[a]s a special case, <host> can
> be the string "localhost" or the empty string; this is interpreted as
> `the machine from which the URL is being interpreted'.". So
> file:///C:/path is a perfectly valid URL for a local file on Windows,
> as a shorthand for file://localhost/C:/path. I'm surprised Unix URLs
> for absolute paths do not start with file:////.

I think the RFC assumes that the leading "/" is not part of the
directory name, so file://<host>/<path> with <host> = localhost and
<path> = /etc/fstab (etc/fstab relative to /) becomes
file:///etc/fstab just like /pub/README on ftp.gnu.org is written as
ftp://ftp.gnu.org/pub/README and not ftp://ftp.gnu.org//pub/README

,----[ rfc1738 ]
| 3.10 FILES
| 
|    The file URL scheme is used to designate files accessible on a
|    particular host computer. This scheme, unlike most other URL schemes,
|    does not designate a resource that is universally accessible over the
|    Internet.
| 
|    A file URL takes the form:
| 
|        file://<host>/<path>
| 
|    where <host> is the fully qualified domain name of the system on
|    which the <path> is accessible, and <path> is a hierarchical
|    directory path of the form <directory>/<directory>/.../<name>.
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

bug#5345: Password asked when visiting a file in a lightweight checkout

[Lennart Borgman]

On Sun, Jan 10, 2010 at 3:10 PM, Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> On Sat, Jan 09 2010, Juanma Barranquero wrote:
>
>> According to RFC 1738 ("Uniform Resource Locators (URL)"),
>> section 3.10 ("FILES"), the syntax is
>>
>>      file://<host>/<path>
>>
>> i.e., the slashes are separators. And "[a]s a special case, <host> can
>> be the string "localhost" or the empty string; this is interpreted as
>> `the machine from which the URL is being interpreted'.". So
>> file:///C:/path is a perfectly valid URL for a local file on Windows,
>> as a shorthand for file://localhost/C:/path. I'm surprised Unix URLs
>> for absolute paths do not start with file:////.
>
> I think the RFC assumes that the leading "/" is not part of the
> directory name, so file://<host>/<path> with <host> = localhost and
> <path> = /etc/fstab (etc/fstab relative to /) becomes
> file:///etc/fstab just like /pub/README on ftp.gnu.org is written as
> ftp://ftp.gnu.org/pub/README and not ftp://ftp.gnu.org//pub/README


That sounds like a plausible reading to me. Shouldn't this then mean
that file://c:/some/file.txt is correct, but that
file:///c:/bad/example.txt is wrong?


> ,----[ rfc1738 ]
> | 3.10 FILES
> |
> |    The file URL scheme is used to designate files accessible on a
> |    particular host computer. This scheme, unlike most other URL schemes,
> |    does not designate a resource that is universally accessible over the
> |    Internet.
> |
> |    A file URL takes the form:
> |
> |        file://<host>/<path>
> |
> |    where <host> is the fully qualified domain name of the system on
> |    which the <path> is accessible, and <path> is a hierarchical
> |    directory path of the form <directory>/<directory>/.../<name>.
> `----
>
> Bye, Reiner.
> --
>       ,,,
>      (o o)
> ---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
>
>
>
>
>

bug#5345: Password asked when visiting a file in a lightweight checkout

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sun, 10 Jan 2010 07:51:44 +0100
> Cc: 5345@debbugs.gnu.org
> 
> Dan Nicolaescu <dann@ics.uci.edu> writes:
> 
> > Can handling as a remote file name be disabled?
> > The code path in question makes sense when the file is local, if the
> > file is remote, then just running the corresponding bzr command won't
> > make a difference.
> 
> Adding "/:" at the top of the file name is one way. Another (maybe more
> common) is let-binding `file-name-handler-alist' to nil.

But the latter is too gross, isn't it?  `file-name-handler-alist'
could hold anything, not just handlers for remote files.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Can handling as a remote file name be disabled?
>> > The code path in question makes sense when the file is local, if the
>> > file is remote, then just running the corresponding bzr command won't
>> > make a difference.
>> 
>> Adding "/:" at the top of the file name is one way. Another (maybe more
>> common) is let-binding `file-name-handler-alist' to nil.
>
> But the latter is too gross, isn't it?  `file-name-handler-alist'
> could hold anything, not just handlers for remote files.

You do it only when you are sure it does not hurt. Wrapping a call to
`file-exists-p', for example.

Best regards, Michael.

bug#5345: Password asked when visiting a file in a lightweight checkout

[Juanma Barranquero]

On Sun, Jan 10, 2010 at 18:48, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> That sounds like a plausible reading to me. Shouldn't this then mean
> that file://c:/some/file.txt is correct, but that
> file:///c:/bad/example.txt is wrong?

Reading that how, exactly?

    Juanma

bug#5345: Password asked when visiting a file in a lightweight checkout

[Lennart Borgman]

On Sun, Jan 10, 2010 at 8:27 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Sun, Jan 10, 2010 at 18:48, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> That sounds like a plausible reading to me. Shouldn't this then mean
>> that file://c:/some/file.txt is correct, but that
>> file:///c:/bad/example.txt is wrong?
>
> Reading that how, exactly?


It is more like a sound ;-)

Reiner whispered that <host> was collapsed to nothing when the url was
local, ie a local file here. Then we get file:///some/file.txt on
un*xes, but on w32 we get the first case above. There is no way to get
the second case on w32 if Reiners suggestion for reading is correct
(and I am not mistaken...)

bug#5345: Password asked when visiting a file in a lightweight checkout

[Juanma Barranquero]

> Reiner whispered that <host> was collapsed to nothing when the url was
> local, ie a local file here.

No, he didn't "whisper" nothing like that. He said that he thinks that
the RFC assumes that the path does not start with a slash.

> There is no way to get
> the second case on w32 if Reiners suggestion for reading is correct
> (and I am not mistaken...)

I think you are.

    Juanma

bug#5345: Password asked when visiting a file in a lightweight checkout

[Lennart Borgman]

On Sun, Jan 10, 2010 at 9:06 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> Reiner whispered that <host> was collapsed to nothing when the url was
>> local, ie a local file here.
>
> No, he didn't "whisper" nothing like that.

Hm. Are you sure?

> He said that he thinks that
> the RFC assumes that the path does not start with a slash.

Yes.

>> There is no way to get
>> the second case on w32 if Reiners suggestion for reading is correct
>> (and I am not mistaken...)
>
> I think you are.

Please explain. How do you get file:/// on w32?

bug#5345: Password asked when visiting a file in a lightweight checkout

[Juanma Barranquero]

On Sun, Jan 10, 2010 at 21:10, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> Hm. Are you sure?

No. Are you sure that he did?

> I think the RFC assumes that the leading "/" is not part of the
> directory name, so file://<host>/<path> with <host> = localhost and
> <path> = /etc/fstab (etc/fstab relative to /)

I certainly read that as written: the leading / is not part of the filename.

>> He said that he thinks that
>> the RFC assumes that the path does not start with a slash.
>
> Yes.

Then, what are we discussing?

> Please explain. How do you get file:/// on w32?

Using the same interpretation (though I'm not sure I agree with it):
the absolute filename does not start with a slash. Surely you don't
want to remove C from C:/my/path?

BTW, please take a look at
http://en.wikipedia.org/wiki/File_URI_scheme  (even if you don't trust
the Wikipedia, the entry is quite informative).

    Juanma

bug#5345: Password asked when visiting a file in a lightweight checkout

[Lennart Borgman]

On Sun, Jan 10, 2010 at 9:21 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Sun, Jan 10, 2010 at 21:10, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> Hm. Are you sure?
>
> No. Are you sure that he did?

Ehum. Yes. But it does not matter.

>> I think the RFC assumes that the leading "/" is not part of the
>> directory name, so file://<host>/<path> with <host> = localhost and
>> <path> = /etc/fstab (etc/fstab relative to /)
>
> I certainly read that as written: the leading / is not part of the filename.
>
>>> He said that he thinks that
>>> the RFC assumes that the path does not start with a slash.
>>
>> Yes.
>
> Then, what are we discussing?
>
>> Please explain. How do you get file:/// on w32?
>
> Using the same interpretation (though I'm not sure I agree with it):
> the absolute filename does not start with a slash. Surely you don't
> want to remove C from C:/my/path?
>
> BTW, please take a look at
> http://en.wikipedia.org/wiki/File_URI_scheme  (even if you don't trust
> the Wikipedia, the entry is quite informative).

Ah, I see what you mean. I still suspect Reiners interpretation is the
same as the one the confused specs, but it does not work on w32 (as
you also said).

bug#5345: Password asked when visiting a file in a lightweight checkout

[Reiner Steib]

On Sun, Jan 10 2010, Lennart Borgman wrote:

> On Sun, Jan 10, 2010 at 9:21 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> BTW, please take a look at
>> http://en.wikipedia.org/wiki/File_URI_scheme  (even if you don't trust
>> the Wikipedia, the entry is quite informative).
>
> Ah, I see what you mean. I still suspect Reiners interpretation is the
> same as the one the confused specs, but it does not work on w32 (as
> you also said).

Well the relative path (starting from the "top level") for /etc/fstab
is etc/fstab, whereas the one for c:/autoexec.bat is c:/autoexec.bat
(not autoexec.bat nor :/autoexec.bat nor /autoexec.bat).

Omitting the drive make no sense on windows.  Omitting the "/"
separator (<host>/<path>) also makes no sense, because it would be
ambiguous ...

E.g. host = sti, c:/k
-->  ftp://sti/c:/k.txt
-->  ftp://stic:/k.txt --> huch?  host = stic, port = emtpy, path = k.txt?

BTW: RFC 1738 is superseded by RFC 2396 and the latter by RFC 3986
(STD 66).  (I didn't read them, though :-))

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/