bzr does not automatically mount + authenticate smb //host/mount style paths on windows

[Tobias Stegmann]

Hi,

when I try to checkout a branch from an access protected directory on my Ubuntu 8.10 machine, Tortoise doesn't show up the authentication window, which the explorer usually shows, and ends up with an permission denied error.

When I open a network connection to this directory before using Tortoise, the checkout and other commands work properly.

Is this a bug or only a missing feature and can s.o. fix/include it?

Thanks,
Tobias

[Stefano Karapetsas (stefano-karapetsas)]

I use TortoiseBZR in the same condition, but once I saved password in the explorer's authentication window, this always works in the next Tortoise accesses (even after a reboot).

[Mark Hammond (mhammond)]

Tobias: thanks for the report - I assume you are using 'qbzr', as tortoisebzr doesn't work anywhere other than windows.

Stefano, I don't completely understand your last comment, as explorer's authentication window shouldn't have a chance to intercept this password request. Could you please clarify your environment and exactly when the authentication window appeared and exactly what it said?

Thanks.

[Tobias Stegmann (punischdude)]

Thanks for your awnser, Mark.

I'm using TortoiseBzr on a Windows XP Prof. enviroment. When I try to checkout a branch, which is located on an Ubuntu machine (could be a Windows, too?), there is no password prompt and I can't connect to smb.

Saving the password, as Stefano suggests, in an Windows Explorer session, works around this issue.

[Alexander Belchenko (bialix)]

Tobias Stegmann пишет:
> Thanks for your awnser, Mark.
>
> I'm using TortoiseBzr on a Windows XP Prof. enviroment. When I try to
> checkout a branch, which is located on an Ubuntu machine (could be a
> Windows, too?), there is no password prompt and I can't connect to smb.
>
> Saving the password, as Stefano suggests, in an Windows Explorer
> session, works around this issue.

QBzr version from trunk now have implemented password dialog.
Can you try it?

[Mark Hammond (mhammond)]

Thanks for the clarification, but I'm still not 100% clear. How exactly is this checkout performed? I'm assuming it must be something like:

* Use Windows Explorer to browse to a directory where you want a local branch.
* Right-click and from the Tortoise context menu, select "Create new Branch/Tree"
* You then must enter the location of the ubuntu branch - what exactly do you specify? given you mention SMB, I assume there must still be a local drive letter mapped, so you specify, eg, "X:\blah". Or do you use a UNC name of "\\server\foo"?

If the latter, then the problem will simply be that the network connection can't be established by bzr, and I believe you would find bzr itself, from the command-line, has the same issue - but I may be on the wrong track completely about exactly what is going on in the first place...

[Tobias Stegmann (punischdude)]

Exactly,

after sharing the branch folder via nautilus sharing dialog in Ubuntu, I go to the directory where I want the branch to be located on my Windows machine,

 * right click on Bazaar "Checkout/Branch"
 * choosing source branch using the "Browse" dialog or by typing \\192.xxx.xxx.xxx\branchDir
 * clicking on "Ok" returns "[Errno 13] Permission denied ..."

I tried it on the command line and there's the same error. Same with latest Qbzr version from trunk.

Thanks

[Mark Hammond (mhammond)]

It should be possible to do this - the big question is how it fits with bzr internals.

When we see a UNC path, we could enumerate all network connections on the box looking for an existing one (WNetOpenEnum/WNetEnumResource/etc). If we can't find the connection we can establish one via the WNetAddConnection functions. Depending on our context, we can pass either a hwnd to the function for an auth dialog, or a flag indicating that the command-line should be used to prompt for a password (or the command will succeed silently if no auth is necessary). pywin32 exposes what is necessary via the win32wnet module.

So the big question is integration with bzr, particularly integration with any existing credentials-gathering it does. Dealing with the hwnd and "am I a console app" question might also be tricky. Hopefully the bzr developers can offer advice on how to move forward on this.

Tobias: the above assumes you see the same behaviour on the command line from both the 'q' versions of the commands, but also from the normal bzr commands - eg "bzr pull" or "bzr branch" - can you please confirm that is true? It would probably also help if the bzr developers can confirm this is an issue for bzr itself (ie, is something bzr would consider addressing in bzrlib)

[Tobias Stegmann (punischdude)]

Indeed, both, i.e. "qbranch" and "branch", return

bzr: ERROR: Permission denied: "//192.168.178.25/normal/.bzr/branch-format": [Errno 13] Permission denied: u'//192.168.178.25/normal/.bzr/branch-format'

[Robert Collins (lifeless)]

On Thu, 2009-01-01 at 07:20 +0000, Mark Hammond wrote:
>
>
> So the big question is integration with bzr, particularly integration
> with any existing credentials-gathering it does. Dealing with the
> hwnd
> and "am I a console app" question might also be tricky. Hopefully the
> bzr developers can offer advice on how to move forward on this.

We have a ui module; I'd be inclined to suggest that the win32 bzr
determine as it starts up if its a gui invocation or a cli, and set an
appropriate ui factory. Then provide a callback into the ui factory (you
may well need to extend it, or the interface may be sufficient - I don't
know). You could use the existing query-for-password method, but I
suspect that really what you want is to know 'am I CLI' and secondly
[for GUI's only] gimme the HWnd.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Mark Hammond (mhammond)]

Thanks for the comments Rob. One clarification: doing this would require some way for bzr to notice we are about to perform a network operation on a UNC (ie, "\\server\foo") and possibly even an already mapped drive (eg, "N:" may be mapped but disconnected) and ask us to establish a connection before the resource is used. Any advice on a clean way to implement such a hook?

[Robert Collins (lifeless)]

On Mon, 2009-01-05 at 04:23 +0000, Mark Hammond wrote:
> Thanks for the comments Rob. One clarification: doing this would
> require some way for bzr to notice we are about to perform a network
> operation on a UNC (ie, "\\server\foo") and possibly even an already
> mapped drive (eg, "N:" may be mapped but disconnected) and ask us to
> establish a connection before the resource is used. Any advice on a
> clean way to implement such a hook?

bzrlib.transport.get_transport() will be called. For UNC paths thats
easy - implement a transport handler with prefix '\\'. (It could just be
an additional registration of Win32LocalTransport even).

As for already mapped drive, Win32LocalTransport could/should catch
exceptions that indicate a need to authenticate and do so.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[obstriegel (obstriegel)]

This bug is still not confirmed. I have the same problem here. We have two people in our team who develop on windows machines. They only can participate in development when the sources are stored in an unprotected location.

We try to access the branch through sftp. I think it is not possible to store a ssh-key in the windows explorer, so the windows users have to use the CLI version or qbzr which is also invoked through the console, which is horrible for windows users.

Also the folders which are versioned with bazaar and are inacessible because of a password take long time to load, I think that is in conjunction with this issue.

Best regards,
Pascal Klein

[bgrupe (bgrupe)]

Just a side note, it is possible to keep the ssh key loaded with putty agent on windows. Bzr will usually recognize it, I haven't tried it with TortoiseBzr just yet though.

[Alexander Belchenko (bialix)]

pageant (putty agent) works fine. it should work with TBZR, because TBZR actually run bzr commands under the hood.

[Gary van der Merwe (garyvdm)]

Needs to be fixed in qbzr, or bzr.

[Robert Collins (lifeless)]

Doesn't look like any bzr changes are needed; just changes to tortoise/qbzr.

[Alexander Belchenko (bialix)]

According to bug description it should be handled by bzr core, because QBzr invokes standard bzr commands under the hood. QBzr per se is able to open dialog to ask password, when bzr asked for it.

[Alexander Belchenko (bialix)]

Robert Collins пишет:
> On Thu, 2009-01-01 at 07:20 +0000, Mark Hammond wrote:
>>
>> So the big question is integration with bzr, particularly integration
>> with any existing credentials-gathering it does. Dealing with the
>> hwnd
>> and "am I a console app" question might also be tricky. Hopefully the
>> bzr developers can offer advice on how to move forward on this.
>
> We have a ui module; I'd be inclined to suggest that the win32 bzr
> determine as it starts up if its a gui invocation or a cli, and set an
> appropriate ui factory. Then provide a callback into the ui factory (you
> may well need to extend it, or the interface may be sufficient - I don't
> know). You could use the existing query-for-password method, but I
> suspect that really what you want is to know 'am I CLI' and secondly
> [for GUI's only] gimme the HWnd.

Robert, this is exactly how QBzr working today.

[Robert Collins (lifeless)]

So, should the bug be closed then?

-Rob

[Alexander Belchenko (bialix)]

Robert Collins пишет:
> So, should the bug be closed then?

Why you asking me? You have marked it as Invalid for bzr.
I'm still think this should be handled in bzr core as for other transports.

IIUC you don't plan to work on any windows-specific improvement.
And this is highly windows-specific thing (UNC/SMB access).

So?

[Robert Collins (lifeless)]

On Tue, 2009-06-16 at 08:26 +0000, Alexander Belchenko wrote:
> Robert Collins пишет:
> > So, should the bug be closed then?
>
> Why you asking me? You have marked it as Invalid for bzr.
> I'm still think this should be handled in bzr core as for other transports.
>
> IIUC you don't plan to work on any windows-specific improvement.
> And this is highly windows-specific thing (UNC/SMB access).
>
> So?

I marked it invalid for bzr based on my understanding of what I read. If
I'm wrong then we shouldn't mark it invalid. I'm asking you because you
are probably the most active bzr dev using windows consistently.

I want to get this bug to the point where there is a clear statement on
what to do next, rather than sitting in limbo.

-Rob

[Alexander Belchenko (bialix)]

Robert Collins пишет:
> On Tue, 2009-06-16 at 08:26 +0000, Alexander Belchenko wrote:
>> Robert Collins пишет:
>>> So, should the bug be closed then?
>> Why you asking me? You have marked it as Invalid for bzr.
>> I'm still think this should be handled in bzr core as for other transports.
>>
>> IIUC you don't plan to work on any windows-specific improvement.
>> And this is highly windows-specific thing (UNC/SMB access).
>>
>> So?
>
> I marked it invalid for bzr based on my understanding of what I read. If
> I'm wrong then we shouldn't mark it invalid. I'm asking you because you
> are probably the most active bzr dev using windows consistently.

Here is analysis from Mark Hammond, and he's definitely more experienced
Windows developer than me:
https://bugs.launchpad.net/tortoisebzr/+bug/297372/comments/7

> I want to get this bug to the point where there is a clear statement on
> what to do next, rather than sitting in limbo.

I don't have the ability to reproduce this bug and therefore don't have
any ideas about how to fix it. And I'm not sure I *can* fix it.

People found workaround for this (open location in Explorer first).

Perhaps bzr should admit that fixing this is too hard right now.
I'm really don't have the answer for you.

[John A Meinel (jameinel)]

So I've run into this a bit before.

Namely, Winamp has the same issue. You can give it a play list which includes files on a remote machine "\\host\music\xxx".

However, if you do that and have not opened the location in Explorer, Winamp will just try endlessly to open each file and fail (it tends to just hang quite painfully at that point).

It is fairly trivial to reproduce, just try to access a non-local file path like "bzr st //host/path/on/host". The idea is that we *could* auto-mount the remote host, and prompt the user for a password if necessary.

That would probably be something that we need to do inside bzr, probably as part of the LocalTransport object.

I'm not 100% sure if we want to do that, but if we are going to support "bzr status //host/mount/path" then I suppose we should.

[John A Meinel (jameinel)]

This shows up as TortoiseBzr not being able to give a password prompt, etc.

[Alexander Belchenko (bialix)]

John A Meinel пишет:
> I'm not 100% sure if we want to do that, but if we are going to support
> "bzr status //host/mount/path" then I suppose we should.

I think this bug affects `bzr pull/push //host/mount/path` operations too.

[John A Meinel (jameinel)]

Sure, it effects any use of "//host/mount/path", I was just using "bzr status" as an example. Probably push/pull are even better examples, though.