Add GetProcCredName implementation to windows gosigar

[eonarheim]

When collecting process information in windows, it is sometimes useful to know the process identity to disambiguate like process (web sites) or identify problem users on a system.

This can be implemented fairly simply with the win32 api bindings in go.

This is related to the topbeats issue elastic/beats#590 and elastic/topbeat#36, basically enables a simple call to gosigar from topbeat to implement.

[andrewkroh]

Check the err status prior the defer CloseHandle.

[andrewkroh]

Thanks for adding this feature. It would be great if you could add a test case to sigar_windows_test.go. You could create a test that compares the username returned by user.Current() to the username returned from the code you added.

[andrewkroh]

When I read UserId I am thinking of a numeric value like a unix UID (or alphanumeric value like a Windows SID). I think I would name this Username like Golang does in their User struct. But that's just one person's opinion, I'm open to hearing others' opinions.

[eonarheim]

@andrewkroh Awesome feedback! I'll work on the updates tomorrow.

[eonarheim]

@andrewkroh Hmm, I could be wrong. But it doesn't look like the current test suite works (unmodified by me) on windows. If I pull down master clean, many of the tests to not run if I run go test

This is one example of a failure. Apologies for the gross formatting :(

←[90m------------------------------←[0m
←[32m+←[0m
←[90m------------------------------←[0m
←[91m←[1m+ Failure [0.049 seconds]←[0m
Sigar
←[90mC:/Projects/GoWorkspace/src/github.com/eonarheim/gosigar/sigar_interface_te
st.go:135←[0m
  ←[91m←[1mproc state [It]←[0m
  ←[90mC:/Projects/GoWorkspace/src/github.com/eonarheim/gosigar/sigar_interface_
test.go:100←[0m

  ←[91mExpected
      <[]string | len:2, cap:2>: ["go", "ginkgo"]
  to contain element matching
      <string>: go.exe←[0m

It looks like all of the failures are coming from the sigar_interface_test.go and concrete_sigar_test.go, it does not seem to account for windows execution, and the differences between the environments. For example in windows programs end with a ".exe" whereas in *nix environments they need not have an extension. There are a few more as well, but it looks like these differences cause the go test command to fail in the default windows experience.

If I run the specific test for windows things are okay.

C:\Projects\GoWorkspace\src\github.com\eonarheim\gosigar [master ≡ +0 ~6 -0 !](g
it prompt time 1.3213683)> go test -v sigar_suite_test.go sigar_windows_test.go
sigar_windows.go
=== RUN   TestGosigar
Running Suite: Gosigar Suite
============================
Random Seed: ←[1m1453330553←[0m
Will run ←[1m3←[0m of ←[1m3←[0m specs

←[32m+←[0m←[32m+←[0m←[32m+←[0m
←[1m←[32mRan 3 of 3 Specs in 0.178 seconds←[0m
←[1m←[32mSUCCESS!←[0m -- ←[32m←[1m3 Passed←[0m | ←[91m←[1m0 Failed←[0m | ←[33m←[
1m0 Pending←[0m | ←[36m←[1m0 Skipped←[0m --- PASS: TestGosigar (0.18s)
=== RUN   TestProcArgs
--- PASS: TestProcArgs (0.68s)
=== RUN   TestProcArgsUnknown
--- PASS: TestProcArgsUnknown (0.65s)
PASS
ok      command-line-arguments  2.235s
C:\Projects\GoWorkspace\src\github.com\eonarheim\gosigar [master ≡ +0 ~6 -0 !](g
it prompt time 2.4007791)>

I've opened an issue about this #14 please correct me if I'm wrong :)

[andrewkroh]

Yeah, I think there are problems with the tests on Windows. Because of this, when I made a change last week I only ran the test cases I added. Windows seems to be in need of some clean up.

[andrewkroh]

Will you please run go fmt to format the code. The changes look good.

[eonarheim]

@andrewkroh Awesome! Looking forward to this feature :)

[andrewkroh]

One more request, can you please squash your commits?

[eonarheim]

Will do

[eonarheim]

Squashed!