Skip to content
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

Open
stuartstein777 opened this issue Aug 30, 2021 · 1 comment
Open

Comments

@stuartstein777
Copy link

stuartstein777 commented Aug 30, 2021

I have this:

func getLogger() (*zap.Logger, error) {
	dir, err := os.Executable()
	if err != nil {
		panic(err)
	}
	fullpath := filepath.Join(filepath.Dir(dir), "proxy.log")
	cfg := zap.NewProductionConfig()
	cfg.OutputPaths = []string{
		fullpath,
	}
	return cfg.Build()
}

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.

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x7ff65d95a787]

However, this works.

func getLogger() (*zap.Logger, error) {
	cfg := zap.NewProductionConfig()
	cfg.OutputPaths = []string{
		"proxy.log",
	}
	return cfg.Build()
}

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.

@abhinav
Copy link
Collaborator

abhinav commented Sep 7, 2021

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 zap.New instead of zap.Config. Given the above, the rough equivalent is:

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
Labels
None yet
Development

No branches or pull requests

2 participants