* bug#5345: Password asked when visiting a file in a lightweight checkout
@ 2010-01-09 2:41 ` Juanma Barranquero
2010-01-09 10:11 ` Michael Albinus
2010-01-09 21:09 ` bug#5345: marked as done (Password asked when visiting a file in a lightweight checkout) Emacs bug Tracking System
0 siblings, 2 replies; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-09 2:41 UTC (permalink / raw
To: Bug-Gnu-Emacs
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 2:41 ` bug#5345: Password asked when visiting a file in a lightweight checkout Juanma Barranquero
@ 2010-01-09 10:11 ` Michael Albinus
2010-01-09 12:44 ` Juanma Barranquero
2010-01-09 21:09 ` bug#5345: marked as done (Password asked when visiting a file in a lightweight checkout) Emacs bug Tracking System
1 sibling, 1 reply; 29+ messages in thread
From: Michael Albinus @ 2010-01-09 10:11 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 5345
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 10:11 ` Michael Albinus
@ 2010-01-09 12:44 ` Juanma Barranquero
2010-01-09 13:52 ` Eli Zaretskii
2010-01-09 18:53 ` Michael Albinus
0 siblings, 2 replies; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-09 12:44 UTC (permalink / raw
To: Michael Albinus; +Cc: 5345
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)
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 12:44 ` Juanma Barranquero
@ 2010-01-09 13:52 ` Eli Zaretskii
2010-01-09 14:36 ` Juanma Barranquero
2010-01-09 18:53 ` Michael Albinus
1 sibling, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2010-01-09 13:52 UTC (permalink / raw
To: Juanma Barranquero, 5345
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 13:52 ` Eli Zaretskii
@ 2010-01-09 14:36 ` Juanma Barranquero
2010-01-09 18:46 ` Dan Nicolaescu
0 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-09 14:36 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 5345, Dan Nicolaescu
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 14:36 ` Juanma Barranquero
@ 2010-01-09 18:46 ` Dan Nicolaescu
2010-01-09 19:06 ` Juanma Barranquero
0 siblings, 1 reply; 29+ messages in thread
From: Dan Nicolaescu @ 2010-01-09 18:46 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 5345
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 12:44 ` Juanma Barranquero
2010-01-09 13:52 ` Eli Zaretskii
@ 2010-01-09 18:53 ` Michael Albinus
1 sibling, 0 replies; 29+ messages in thread
From: Michael Albinus @ 2010-01-09 18:53 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 5345
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 18:46 ` Dan Nicolaescu
@ 2010-01-09 19:06 ` Juanma Barranquero
2010-01-09 19:20 ` Dan Nicolaescu
0 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-09 19:06 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 5345
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 19:06 ` Juanma Barranquero
@ 2010-01-09 19:20 ` Dan Nicolaescu
2010-01-09 20:08 ` Juanma Barranquero
2010-01-09 21:15 ` Michael Albinus
0 siblings, 2 replies; 29+ messages in thread
From: Dan Nicolaescu @ 2010-01-09 19:20 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 5345
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 19:20 ` Dan Nicolaescu
@ 2010-01-09 20:08 ` Juanma Barranquero
2010-01-09 20:39 ` Dan Nicolaescu
2010-01-10 14:10 ` Reiner Steib
2010-01-09 21:15 ` Michael Albinus
1 sibling, 2 replies; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-09 20:08 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 5345
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))
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 20:08 ` Juanma Barranquero
@ 2010-01-09 20:39 ` Dan Nicolaescu
2010-01-09 20:57 ` Lennart Borgman
2010-01-10 14:10 ` Reiner Steib
1 sibling, 1 reply; 29+ messages in thread
From: Dan Nicolaescu @ 2010-01-09 20:39 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 5345
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 20:39 ` Dan Nicolaescu
@ 2010-01-09 20:57 ` Lennart Borgman
2010-01-09 21:04 ` Juanma Barranquero
0 siblings, 1 reply; 29+ messages in thread
From: Lennart Borgman @ 2010-01-09 20:57 UTC (permalink / raw
To: Dan Nicolaescu, 5345; +Cc: Juanma Barranquero
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 20:57 ` Lennart Borgman
@ 2010-01-09 21:04 ` Juanma Barranquero
2010-01-09 21:12 ` Lennart Borgman
0 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-09 21:04 UTC (permalink / raw
To: Lennart Borgman; +Cc: Dan Nicolaescu, 5345
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: marked as done (Password asked when visiting a file in a lightweight checkout)
2010-01-09 2:41 ` bug#5345: Password asked when visiting a file in a lightweight checkout Juanma Barranquero
2010-01-09 10:11 ` Michael Albinus
@ 2010-01-09 21:09 ` Emacs bug Tracking System
1 sibling, 0 replies; 29+ messages in thread
From: Emacs bug Tracking System @ 2010-01-09 21:09 UTC (permalink / raw
To: Juanma Barranquero; +Cc: emacs-bug-tracker
[-- 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 21:04 ` Juanma Barranquero
@ 2010-01-09 21:12 ` Lennart Borgman
0 siblings, 0 replies; 29+ messages in thread
From: Lennart Borgman @ 2010-01-09 21:12 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Dan Nicolaescu, 5345
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
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 19:20 ` Dan Nicolaescu
2010-01-09 20:08 ` Juanma Barranquero
@ 2010-01-09 21:15 ` Michael Albinus
2010-01-09 21:33 ` Dan Nicolaescu
1 sibling, 1 reply; 29+ messages in thread
From: Michael Albinus @ 2010-01-09 21:15 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 5345
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 21:15 ` Michael Albinus
@ 2010-01-09 21:33 ` Dan Nicolaescu
2010-01-10 6:51 ` Michael Albinus
0 siblings, 1 reply; 29+ messages in thread
From: Dan Nicolaescu @ 2010-01-09 21:33 UTC (permalink / raw
To: Michael Albinus; +Cc: 5345
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 21:33 ` Dan Nicolaescu
@ 2010-01-10 6:51 ` Michael Albinus
2010-01-10 17:52 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: Michael Albinus @ 2010-01-10 6:51 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 5345
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-09 20:08 ` Juanma Barranquero
2010-01-09 20:39 ` Dan Nicolaescu
@ 2010-01-10 14:10 ` Reiner Steib
2010-01-10 17:48 ` Lennart Borgman
1 sibling, 1 reply; 29+ messages in thread
From: Reiner Steib @ 2010-01-10 14:10 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 5345
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/
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 14:10 ` Reiner Steib
@ 2010-01-10 17:48 ` Lennart Borgman
2010-01-10 19:27 ` Juanma Barranquero
0 siblings, 1 reply; 29+ messages in thread
From: Lennart Borgman @ 2010-01-10 17:48 UTC (permalink / raw
To: Reiner Steib, 5345, Juanma Barranquero
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/
>
>
>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 6:51 ` Michael Albinus
@ 2010-01-10 17:52 ` Eli Zaretskii
2010-01-10 19:07 ` Michael Albinus
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2010-01-10 17:52 UTC (permalink / raw
To: Michael Albinus, 5345
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 17:52 ` Eli Zaretskii
@ 2010-01-10 19:07 ` Michael Albinus
0 siblings, 0 replies; 29+ messages in thread
From: Michael Albinus @ 2010-01-10 19:07 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 5345
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 17:48 ` Lennart Borgman
@ 2010-01-10 19:27 ` Juanma Barranquero
2010-01-10 19:40 ` Lennart Borgman
0 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-10 19:27 UTC (permalink / raw
To: Lennart Borgman; +Cc: 5345, Reiner Steib
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 19:27 ` Juanma Barranquero
@ 2010-01-10 19:40 ` Lennart Borgman
2010-01-10 20:06 ` Juanma Barranquero
0 siblings, 1 reply; 29+ messages in thread
From: Lennart Borgman @ 2010-01-10 19:40 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 5345, Reiner Steib
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...)
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 19:40 ` Lennart Borgman
@ 2010-01-10 20:06 ` Juanma Barranquero
2010-01-10 20:10 ` Lennart Borgman
0 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-10 20:06 UTC (permalink / raw
To: Lennart Borgman; +Cc: 5345, Reiner Steib
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 20:06 ` Juanma Barranquero
@ 2010-01-10 20:10 ` Lennart Borgman
2010-01-10 20:21 ` Juanma Barranquero
0 siblings, 1 reply; 29+ messages in thread
From: Lennart Borgman @ 2010-01-10 20:10 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 5345, Reiner Steib
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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 20:10 ` Lennart Borgman
@ 2010-01-10 20:21 ` Juanma Barranquero
2010-01-10 20:35 ` Lennart Borgman
0 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-10 20:21 UTC (permalink / raw
To: Lennart Borgman; +Cc: 5345, Reiner Steib
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 20:21 ` Juanma Barranquero
@ 2010-01-10 20:35 ` Lennart Borgman
2010-01-12 18:09 ` Reiner Steib
0 siblings, 1 reply; 29+ messages in thread
From: Lennart Borgman @ 2010-01-10 20:35 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 5345, Reiner Steib
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).
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#5345: Password asked when visiting a file in a lightweight checkout
2010-01-10 20:35 ` Lennart Borgman
@ 2010-01-12 18:09 ` Reiner Steib
0 siblings, 0 replies; 29+ messages in thread
From: Reiner Steib @ 2010-01-12 18:09 UTC (permalink / raw
To: Lennart Borgman; +Cc: 5345
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/
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2010-01-12 18:09 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <f7ccd24b1001091308y34abf466j1424a588134a83e6@mail.gmail.com>
2010-01-09 2:41 ` bug#5345: Password asked when visiting a file in a lightweight checkout Juanma Barranquero
2010-01-09 10:11 ` Michael Albinus
2010-01-09 12:44 ` Juanma Barranquero
2010-01-09 13:52 ` Eli Zaretskii
2010-01-09 14:36 ` Juanma Barranquero
2010-01-09 18:46 ` Dan Nicolaescu
2010-01-09 19:06 ` Juanma Barranquero
2010-01-09 19:20 ` Dan Nicolaescu
2010-01-09 20:08 ` Juanma Barranquero
2010-01-09 20:39 ` Dan Nicolaescu
2010-01-09 20:57 ` Lennart Borgman
2010-01-09 21:04 ` Juanma Barranquero
2010-01-09 21:12 ` Lennart Borgman
2010-01-10 14:10 ` Reiner Steib
2010-01-10 17:48 ` Lennart Borgman
2010-01-10 19:27 ` Juanma Barranquero
2010-01-10 19:40 ` Lennart Borgman
2010-01-10 20:06 ` Juanma Barranquero
2010-01-10 20:10 ` Lennart Borgman
2010-01-10 20:21 ` Juanma Barranquero
2010-01-10 20:35 ` Lennart Borgman
2010-01-12 18:09 ` Reiner Steib
2010-01-09 21:15 ` Michael Albinus
2010-01-09 21:33 ` Dan Nicolaescu
2010-01-10 6:51 ` Michael Albinus
2010-01-10 17:52 ` Eli Zaretskii
2010-01-10 19:07 ` Michael Albinus
2010-01-09 18:53 ` Michael Albinus
2010-01-09 21:09 ` bug#5345: marked as done (Password asked when visiting a file in a lightweight checkout) Emacs bug Tracking System
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.