Unable to use absolute path to log file on Windows

[d1vanloon]

Summary

Setting an absolute path to the log file (the default) prevents the application from launching on Windows.

Steps to Reproduce

Environment: superhighway84 v0.0.4 on Windows build 22000.348

1. Execute superhighway84.exe
2. Accept the defaults for the Initial Setup prompts
3. Specify a From name and accept other profile defaults

Expected Result

The application launches.

Actual Result

The application crashes with the following message:

SUPERHIGHWAY84

Initial Setup
-------------

Database connection string [/orbitdb/bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4/superhighway84]:
Database cache path [C:\Users\username/.cache/superhighway84]:
Logfile path [C:\Users\username/.cache/superhighway84.log]:

Profile information
-------------------

From [@localhost]: username123
Organization []:
2021/12/28 00:45:28 couldn't open sink "C:\\Users\\username/.cache/superhighway84.log": no sink found for scheme "c"
panic: couldn't open sink "C:\\Users\\username/.cache/superhighway84.log": no sink found for scheme "c"

goroutine 1 [running]:
log.Panicln({0xc00171ff50, 0x28, 0x29c6847bb11})
        /opt/hostedtoolcache/go/1.17.5/x64/src/log/log.go:368 +0x65
main.main()
        /home/runner/work/superhighway84/superhighway84/superhighway84.go:42 +0x1a5

Workaround

Set a relative path for the log file.

Unfortunately, this is not a permanent fix as the log file will be recreated several times based on the working directory from which the application was launched.

Notes

This seems related to parsing Windows paths in the logging module.

[altilunium]

Maybe related : https://github.com/uber-go/zap/issues/621

[mrusme]

Oh boy, well, the zap situation kind of sucks. I actually didn't plan on using it, but I saw that OrbitDB and IPFS used it as Logger so I thought why not.

The error described here comes from my own code though, and I will be able to fox that. As for zap it seems IPFS have fixed it before: https://github.com/ipfs/go-log/commit/45b384fa48c412c15e9f15cff6c3077b8d85211e

I'll likely take a similar approach to get it running. Thanks for pointing it out and providing further info!

[altilunium]

(Very crude) windows port, by me : https://github.com/altilunium/superhighway84

[mrusme]

Hey there @altilunium, thanks for getting it working! How about creating a proper PR for the changes, so we can incorporate them into the official release? :-)

[d1vanloon]

Based on previous discussion I updated the issue title and added a temporary workaround.

[mrusme]

Thanks! Maybe you want to give the current master a try. I've moved to filepath, which I believe should be OS-agnostic. I don't have a windows machine available for testing, so all I can do here is basically try things that should work in theory.

[d1vanloon]

Tested on v0.0.5-4-g803fa84 with the following result:

SUPERHIGHWAY84

Initial Setup
-------------

Database connection string [/orbitdb/bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4/superhighway84]:
Database cache path [C:\Users\username\.cache\superhighway84]:
Logfile path [C:\Users\username\.cache\superhighway84.log]:

Profile information
-------------------

From [@localhost]: username123
Organization []:
2021/12/28 20:13:30 couldn't open sink "C:\\Users\\username\\.cache\\superhighway84.log": no sink found for scheme "c"
panic: couldn't open sink "C:\\Users\\username\\.cache\\superhighway84.log": no sink found for scheme "c"

goroutine 1 [running]:
log.Panicln({0xc001829f50, 0x28, 0x1d170100108})
        C:/Program Files/Go/src/log/log.go:368 +0x65
main.main()
        C:/Users/username/Source/Repos/github/mrusme/superhighway84/superhighway84.go:42 +0x1a5

This is a slightly different result - it looks like the paths are correctly formatted for Windows, but the log provider still can't interpret the path.

[mrusme]

@d1vanloon if you don't mind you might test with the latest master again. I committed a changed to the NewLogger function which might fix the issue you're experiencing on Windows.

[d1vanloon]

I tested on v0.0.6-3-g2781f76 and was unable to reproduce the issue. Thank you for investigating!