Comment 1:

[1] A suitable behavior for user.Current() might be to return only what a API user may
intuitively expect: a OS user name as a string (instead of User struct)
But unfortunately, user.Current() is an interface that is already present in officially
released version of Go :(
Next best option might be to return the user struct but fill only the username with rest
of the fields in initialized state.
This avoids a network access when not needed thereby saving time and not needing error
handling when not needed.
[2] Relevance for other exported functions
* The problem seems to exist in windows version of user.Lookup() and user.LookupId() as
well
* This problem is not as relevant for posix systems since AFAIK, a network authenticated
user cannot login if the auth server is down. Nevertheless, based on change done for the
windows implementation, it is best modified accordingly for a consistent behavior.
[3] If wanting to expose different user information one may consider introducing
additional exported functions.

Comment 2:

This issue is not about changing any interface. It is about making our current test PASS
in every possible situation. You have discovered a scenario of when our test fails, so
we should adjust things accordingly make it PASS. I do not know how to do it yet.
Alex

Comment 3:

Please check the suitability of the patch I am submitting
(I am having problems with codereview extension as of now)
It is possible to get the tests to pass with the below change to lookupFullName()
Hence the comment above behavior of the interface in point #1
func lookupFullName(domain, username, domainAndUser string) (string, error) {
    return username, nil
}
I am attaching a patch as a fix candidate. I have tested it with for computer part of
the domain as well as without.
Changes are as below:
lookupFullName() instead of calling syscall.TranslateAccountName() calls
syscall.GetUserNameEx()
The expected behavior of GetUserNameEx() is that if the computer is not part of the
domain it picks the information from local OS cache else it gets from domain controller.
One quirk here is that - as per documentation (check URLs below) if the user is not in a
domin, GetUserNameEx() is expected to support only NameSamCompatible. But in reality, it
actually supports NameDisplay as per test results - this is good for this issue.
http://msdn.microsoft.com/en-us/library/ms902883.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724435(v=vs.85).aspx

Attachments:

1. go_bug_4113.patch (2400 bytes)

Comment 4:

It is possible to get the tests to pass with the below change to lookupFullName(). Hence
my comment about interface behavior. For the current interface this might be OK.
func lookupFullName(domain, username, domainAndUser string) (string, error) {
    return username, nil
}
Seems like a better fix is possible as below:
lookupFullName() instead of calling syscall.TranslateAccountName() calls
syscall.GetUserNameEx()
The expected behavior of GetUserNameEx() is that if the computer is not part of the
domain it picks the information from local OS cache else it gets from domain controller.
I have tested it with both positive & negative cases.
One quirk here is that - as per documentation (URLs below) if the user is not in a
domin, GetUserNameEx() is expected to support only NameSamCompatible. But in reality, it
actually supports NameDisplay as per test results - this is good for this issue.
This is what has been used since not using it would reduce the situation to the trivial
fix I suggested at the start.
http://msdn.microsoft.com/en-us/library/ms902883.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724435(v=vs.85).aspx

Attachments:

1. go_bug_4113.patch (2400 bytes)

Comment 5:

Perhaps,
func lookupFullName(domain, username, domainAndUser string) (string, error) {
    return username, nil
}
will work, but that is cheating. The lookupFullName should uncover user's "full name",
not user "account name". Perhaps, in some situations that is apropriate, but not as a
general solution.
Alex

Comment 6:

This issue was closed by revision 5f7f906.

Status changed to Fixed.