"Win32 file urls start with file:///x:/, where x is a valid drive letter" error in _win32_local_path_from_url in auto_upload_hook

[Cameron P]

When I commit changes from a windows box (with 2.0.2 installed) to a linux central repository (with lastest version installed, plus upload plugin) I get the following error

bzr: ERROR: Invalid url supplied to transport: "file:///home/abc/public_html/abc/": Win32 file urls start with file:///x:/, where x is a valid drive letter

If I turn off the --auto feature on the server, then commit, it works with no errors.

Below is the bzr log from the windows client:

Mon 2009-10-05 14:36:09 +1000
0.087 bzr arguments: [u'qsubprocess', u'"commit" "-m" "try with auto on." "CHANGELOG.txt"']
0.108 looking for plugins in C:/Users/x.x/AppData/Roaming/bazaar/2.0/plugins
0.108 looking for plugins in C:/Program Files/Bazaar/plugins
0.290 encoding stdout as osutils.get_user_encoding() 'cp1252'
0.392 bzr arguments: [u'commit', u'-m', u'try with auto on.', u'CHANGELOG.txt']
0.396 encoding stdout as osutils.get_user_encoding() 'cp1252'
0.438 opening working tree 'C:/devel/x'
0.536 bzr-svn: using Subversion 1.5.6 ()
0.740 falling back to default implementation
0.741 failed to load system host keys: [Errno 2] No such file or directory: 'H:\\/.ssh/known_hosts'
[ 5312] 2009-10-05 14:36:10.565 INFO: Connected (version 2.0, client OpenSSH_4.3)
[ 5312] 2009-10-05 14:36:12.267 INFO: Authentication (password) successful!
[ 5312] 2009-10-05 14:36:12.474 INFO: Secsh channel 1 opened.
5.369 preparing to commit
[ 5312] 2009-10-05 14:36:16.779 INFO: Committing to: bzr+ssh://<email address hidden>/home/developm/repository/belzebuub/
7.320 Selecting files for commit with filter [u'CHANGELOG.txt']
[ 5312] 2009-10-05 14:36:17.331 INFO: modified CHANGELOG.txt
8.645 Using fetch logic to copy between KnitPackRepository('file:///C:/devel/x/.bzr/repository/')(<RepositoryFormatKnitPack1>) and RemoteRepository(bzr+ssh://<email address hidden>/home/x/repository/.bzr/)(<RemoteRepositoryFormat>)
8.645 fetch up to rev {<email address hidden>}
11.105 encoding stdout as osutils.get_user_encoding() 'cp1252'
11.415 Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 842, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1037, in run_bzr
  File "bzrlib\commands.pyo", line 654, in run_argv_aliases
  File "C:/Program Files/Bazaar/plugins\qbzr\lib\commands.py", line 774, in run
  File "bzrlib\commands.pyo", line 1037, in run_bzr
  File "bzrlib\commands.pyo", line 654, in run_argv_aliases
  File "bzrlib\builtins.pyo", line 3051, in run
  File "bzrlib\decorators.pyo", line 192, in write_locked
  File "bzrlib\workingtree_4.pyo", line 197, in commit
  File "bzrlib\decorators.pyo", line 192, in write_locked
  File "bzrlib\mutabletree.pyo", line 228, in commit
  File "bzrlib\commit.pyo", line 393, in commit
  File "bzrlib\branch.pyo", line 910, in import_last_revision_info
  File "bzrlib\decorators.pyo", line 192, in write_locked
  File "bzrlib\remote.pyo", line 2578, in set_last_revision_info
  File "bzrlib\branch.pyo", line 1081, in _run_post_change_branch_tip_hooks
  File "\plugins\upload\auto_upload_hook.py", line 41, in auto_upload_hook
  File "bzrlib\urlutils.pyo", line 588, in unescape_for_display
  File "bzrlib\urlutils.pyo", line 261, in _win32_local_path_from_url
InvalidURL: Invalid url supplied to transport: "file:///home/x/public_html/x/": Win32 file urls start with file:///x:/, where x is a valid drive letter

11.416 return code 3
[ 4172] 2009-10-05 14:36:52.240 ERROR: Error processing remote request
Traceback (most recent call last):
  File "tbzrlib\pipe\server.pyo", line 132, in run_command_loop
  File "tbzrlib\dispatcher.pyo", line 200, in dispatch
  File "tbzrlib\dispatcher.pyo", line 115, in get_menu_commands
  File "tbzrlib\actions.pyo", line 342, in get_actions_for_files
  File "tbzrlib\cache\wtcache.pyo", line 142, in is_path_allowed
TypeError: cannot concatenate 'str' and 'NoneType' objects
[ 4172] 2009-10-05 14:36:52.242 ERROR: Error processing remote request
Traceback (most recent call last):
  File "tbzrlib\pipe\server.pyo", line 132, in run_command_loop
  File "tbzrlib\dispatcher.pyo", line 200, in dispatch
  File "tbzrlib\dispatcher.pyo", line 115, in get_menu_commands
  File "tbzrlib\actions.pyo", line 342, in get_actions_for_files
  File "tbzrlib\cache\wtcache.pyo", line 142, in is_path_allowed
TypeError: cannot concatenate 'str' and 'NoneType' objects

Thanks,
Cameron

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> ** Summary changed:
>
> - error with --auto feature turned on with bzr 2.0.0-2
> + "Win32 file urls start with file:///x:/, where x is a valid drive letter" error in _win32_local_path_from_url in auto_upload_hook
>

So I think this is actually a bug in bzr-upload, and what is happening
is that committing to that branch wants to push the changes to the
remote site, and then upload those to yet another location. However from
the sound of it, we don't actually have *access* to that location,
because it is given as a file:/// url on the remote host.

I don't know if there is much bzr can do...

  affects bzr-upload

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrKAM8ACgkQJdeBCYSNAAOMvQCeLaAQNfi3c3HuimWD1xNAThQk
QmsAoNcM/qbNLMQEO0sBBwetCOloyyro
=edy6
-----END PGP SIGNATURE-----

[Vincent Ladeuil (vila)]

Can you give some details on the setup you use here ?
Based on 'bzr info' output on what you call the client and the server.

From the backtrace the bug occurs on the client (windows)
but you said you turned off the --auto feature on the server (linux ?).

Also can you explain what setup you're using here ?

[Cameron P (cameronprice)]

Sure, Client side: Windows Vista x64
D:\files\xyz\website\belzebuub\site\belzebuub>bzr info
Checkout (format: unnamed)
Location:
       checkout root: .
  checkout of branch: bzr+ssh://<email address hidden>/home/developm/repository/belzebuub/

Server: Fresh install of Centos 5.3 64bit
built from latest checkout
Repository tree (format: unnamed)
Location:
  shared repository: /home/developm/repository
  repository branch: .

Yeah so if I turn off the auto feature on the server (the auto feature is used to auto load to a test site sitting onthat server) it works ok.

Let me know if you need any more info

[Vincent Ladeuil (vila)]

Can you make it work if you use a bound branch instead of a lightweight checkout on your client ?
I suspect we never expected to be used in a config like yours :-P

When you say you turn the --auto feature on or off on the server it is because you actually
issue the commands on the server or because you issue them on the client but know that
the branch is on the server ?

In any case, can you show us the branch.conf file (look into the .bzr/branch file in
 the branch directory, so on the server).

[Cameron P (cameronprice)]

Hi Vincent, In theory I thought I did set it up as a bound branch, or thats what i thought?
Basically I just do local commits, and it knows Im bound to a branch and commits it to the server shared repository

Yeah I turn of the --auto feature on the server (I have bzr installed on the server also, since it is holding the shared repository) - it also is the machine that has the upload plugin installed.

What have I done with the config that looks so unique ? heh

thanks,
Cameron

[Kevin Kaland (kkaland)]

Hi Vincent,

Any progress on this one? We turned --auto back on recently, and I'm even getting problems committing from my local checkout. Is it unusual to have bzr upload on both the shared repository's server and my own local testing VM (Ubuntu 10.04)? It seems like my local bzr-upload tries to auto-upload after the server! Of course, I don't want it to do that. Can I tell it to ignore the branch somehow? There ARE other branches I do want to be able to up the date.

Thanks,
Kevin

[Vincent Ladeuil (vila)]

As asked previously, can you attach the relevant .branch.conf files and the output of 'bzr info -v' it's a bit hard
to guess your config otherwise.

[Kevin Kaland (kkaland)]

Hi Vincent,

Sure, here you go. They are attached. I'm not sure if this might also be related to this one that I get when committing to our shared repository, which has automatic upload enabled, from my Ubuntu Linux machine:

bzr: ERROR: No such file: u'/home/developm/www/gnosticawakenings/': [Errno 2] Aucun fichier ou dossier de ce type: '/home/developm/www/gnosticawakenings/'

It's probably more related to the fact that *I* have bzr upload installed as well as the server, but anyway it's an annoyance since then I have to do another bzr update to get in sync. Just though to mention it in passing, not sure if it helps.

Thanks,
Kevin

[Vincent Ladeuil (vila)]

Sorry for the delay,

I think you forgot to post a config file there, probably on the server side since nothing in the one you provided refers to bzr-upload.

The 'Branch is out of date: missing 131 revisions.' in the 'bzr info -v' output is also worrying,
can you run a 'bzr update' there ?

I suspect you setup a bad config file on the server but if you can provide it it will be easier to diagnose.

[Kevin Kaland (kkaland)]

Sorry for the delay again. Here's bzr info -v again with the problem happening.

B:\dev\gnostica>bzr info -v
Checkout (format: unnamed)
Location:
       checkout root: .
  checkout of branch: bzr+ssh://<email address hidden>:6475/home/developm/r
epository/gnosticawakenings/

Format:
       control: Meta directory format 1
  working tree: Working tree format 6
        branch: Branch format 6
    repository: Repository format 2a - rich roots, group compression and chk inv
entories

branch.conf attached (from local machine)
branch-server.conf attached (from server's branch.conf, but note that upload --auto is turned off...) - oh, I can only attach one file, will attach in new comment

Do you think putting the server's own public key in its authorized keys and forcing it to use a bzr+ssh path (instead of direct) to itself would be a workaround? I saw one gentleman up there said that that is probably the cause - that Windows didn't recognize the file:/// URL. And I can sort of confirm that because my own local Linux box made a similar complaint; it just wasn't fatal for whatever reason, but it actually does get in the way of server operations and being able to fix the branch by updating for Windows users.

[Kevin Kaland (kkaland)]

the server's branch.conf