-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: WIndows - How to specify full path to log file name #994
Comments
Hey there! It looks like Zap (or at least zap.Config) doesn't quite work on Windows yet (experimented in #999). I'll create a separate task for Windows support, but meanwhile, you should be able to work around this issue by constructing a logger directly with enc := zapcore.NewJSONEncoder(zap.NewProductionEncoderConfig())
ws, err := os.OpenFile(fullpath, os.O_WRONLY|os.O_APPEND|os.O_CREATE, 0666)
if err != nil { ... }
core := zapcore.NewCore(enc, ws, zapcore.InfoLevel)
logger := zap.New(core) |
abhinav
added a commit
that referenced
this issue
Nov 20, 2021
We use `newSink` to decide where the zap.Config.OutputPaths field intends to send logs. It can be in the form, file:///foo/bar # or equivalently, /foo/bar Or a user can register a custom sink constructor with `RegisterSink`, and then use the specified scheme in the output paths. zap.RegisterSink("myscheme", ...) zap.Config{ OutputPaths: []string{ "myscheme://whatever/I/want", }, } This method of configuration hasn't worked for Windows (ref #994) because we use `url.Parse` to parse these output paths. `url.Parse` parses a Windows file path like `C:\foo\bar` to the URL: URL{ Scheme: "c", Opaque: `\foo\bar`, } This commit adds support for Windows file paths. It does so by converting "\" symbols in the output path with "/" before attempting to parse it with url.Parse. This gives us, URL{ Scheme: "c", Path: "/foo/bar", } Following that, we check if the scheme matches the path's "volume name". On Windows, the volume name of `C:\foo\bar` is `"C"`. On Unix, the volume name of all paths is `""`. This lets us convert the partial file path in the URL back to a valid Windows file path and set the scheme to "file" to use the file sink.
abhinav
added a commit
that referenced
this issue
Nov 20, 2021
We use `newSink` to decide where the zap.Config.OutputPaths field intends to send logs. It can be in the form, file:///foo/bar # or equivalently, /foo/bar Or a user can register a custom sink constructor with `RegisterSink`, and then use the specified scheme in the output paths. zap.RegisterSink("myscheme", ...) zap.Config{ OutputPaths: []string{ "myscheme://whatever/I/want", }, } This method of configuration hasn't worked for Windows (ref #994) because we use `url.Parse` to parse these output paths. `url.Parse` parses a Windows file path like `C:\foo\bar` to the URL: URL{ Scheme: "c", Opaque: `\foo\bar`, } This commit adds support for Windows file paths. It does so by converting "\" symbols in the output path with "/" before attempting to parse it with url.Parse. This gives us, URL{ Scheme: "c", Path: "/foo/bar", } Following that, we check if the scheme matches the path's "volume name". On Windows, the volume name of `C:\foo\bar` is `"C:"`. On Unix, the volume name of all paths is `""`. This lets us convert the partial file path in the URL back to a valid Windows file path and set the scheme to "file" to use the file sink.
abhinav
pushed a commit
that referenced
this issue
Sep 12, 2022
Ref #994, #1000 Alternate approach to #999, this approach brings absolute path support to Windows. It does so by checking for absolute paths and handling them using the file factory directly. To test different paths without trying to actually open them (UNC paths hit the network), this change also prefactors the sink registry into a separate type that allows stubbing of the `os.OpenFile` call. Note: This change does not bring full Windows support -- many tests still fail, and Windows file URIs don't work.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have this:
fullpath here is
C:\Users\stuarts\Source\sentilan-agent-proxy-api\proxy.log
When I try to log I get a nil dereference error. The logger that is returned is nil.
However, this works.
This logs to proxy.log in the same folder as the .exe, But we are running this s a service and its causing the file to be logged to windows system folder (as this is the working folder when its run a service).
What am I doing wrong here? I'd like to specify a full path to log file.
The text was updated successfully, but these errors were encountered: