Add setting to allow for custom log path

[SimonWahlin]

Summary of the new feature

Running VSCode as a non-administrator I don't have write-access to the extensions folder.
This causes the PowerShell extension to fail to load when trying to write to the logs subfolder of the PowerShell extension folder.

To be able to load the extension without write-access to the extensions directory I would like to configure the extension to either turn of logging completely or configure the path to the logs folder to a folder where the user has write access.

Proposed technical implementation details (optional)
Any or all of the following:

• Add setting to make the logs path configurable.
• Add setting(s) to disable logging and anything else that will cause writes to the extensions folder.

[rkeithhill]

Running VSCode as a non-administrator I don't have write-access to the extensions folder.

What OS? I've only used the PowerShell extension as a standard user on both Windows and Ubuntu and never had any problems with the extension writing to the logs dir.

VSCode extensions are typically installed under the user's home dir where the user, running as a standard user, should have write perms. In fact, if the extension couldn't write to the logs dir, it probably couldn't write to the sessions dir which means the extension would never be able to attach to language/debug server.

[SimonWahlin]

The problem occurs when using application whitelisting.

Putting the extensions folder where a user can write makes for complex white-listing scenarios. Putting the extensions folder where user can not write works for most extensions and allows for a simple path whitelisting.

I see, then the sessions folder will be a problem as well. Will the extension only store data in the session or does it need to execute code from there? Would it be possible to alsp have the sessionpath configurable?

[rkeithhill]

Rather than adding multiple settings that require user configuration to make work in this scenario, perhaps we should write logs/session info to the user's appdata/local folder? If we did this, I'd also like to look at periodically deleting old log folders. Right now, we create a new log folder for every new session and pretty much the only way those get cleaned up now is when you update to a newer version of the extension (and the old version is removed).

[SimonWahlin]

That sounds like a great idea!

[rkeithhill]

So who knows what the appropriate location for the session & log files would be for Linux and macOS? Or maybe we only make this change for Windows since app whitelisting is only an issue on Windows? Not sure I like having different ways of handling these files for different platforms. Thoughts?

[rjmholt]

On macOS I think it's here: https://stackoverflow.com/questions/9495503/applications-data-folder-in-mac

Linux is not so simple -- there's a few possible answers (https://unix.stackexchange.com/questions/65389/where-are-userspace-programs-supposed-to-save-their-logs, https://www.quora.com/What-is-the-best-Unix-Linux-directory-to-store-data-var-lib-etc-*something*-something-else, https://stackoverflow.com/questions/1510104/where-to-store-application-data-non-user-specific-on-linux). Somewhere under $HOME seems appropriate for us -- so maybe we are already good on that front?

[yume-chan]

I'm using OneDrive to sync my Code profile, and today I was surprised that OneDrive is uploading a 2.2GB file and it belongs to the PowerShell extension.

I always expect the extension folder is kind-of read-only. Logs and temporary files should be in my temp folder and be cleaned periodically.

[TylerLeonhardt]

We could always use something like:

[System.IO.Path]::GetTempPath()

which works cross platform.

But then we need a cleanup scenario.

[rkeithhill]

Couple that temp path with a subdir like vscode-powershell\sessions and vscode-powershell\logs? OTOH I thought that on Linux/macOS there were prescribed locations for log files? /var/log on Linux, right?

[rjmholt]

@yume-chan Your issue there is probably orthogonal to controlling the log path.

I think there are two problems you might be hitting:

1. Logs seem to get stuck in a loop sometimes and basically dump output as fast as they can push IO, which is a categorical bug.
2. Logs should have a configurable lifetime, so they don't just massively build up over time.

The temp directory suggestion has a couple of issues:

• The convention for application logs is to write them to an AppData-type location -- writing logs to the system temp directory would make us a bit unusual as an application. Also the temp directory seems to work differently on every platform, so implementing things that way will be more error-prone and less predictable for users.
• We have no control over how often the temp directory gets cleaned. It makes sense to clean out the logs, but I feel like it should be up to you as a user, not an implementation detail of your host OS.

If you've got time, can you please open a new issue about the large output of the logfiles you're experiencing? And/or wanting to periodically delete logs?

@rkeithhill it feels like /var/log/ is for system daemon logs, like systemd, XOrg, cups. From what I looked into, there's no standard application data log location on linux. There was a suggestion that we use the systemd log tools but that uses a binary format and there are probably plenty of reasons not to go that way. For user-specific applications, the suggestion seems to be that we want a dotfile in $HOME - but going that path we should probably work out how to best separate that from the present implementation. For Linux' purposes, we might already be doing "the right thing" for logs.

[TylerLeonhardt]

I tried to see if AppData was set in .NET on macOS and sadly, it's not.

System.Environment.GetEnvironmentVariables() gave me an APPDATA on Windows but no APPDATA on macOS.

TEMP was there on both.

So the options seem to be:

• Use Temp - less complex but not standard
• Conditionally use a different location based on OS - more complicated but uses the "right" folders

I think there's also a 3rd option... if we have access to the normal path we're using now, keep it. If we can't write to it, then maybe we have a back up (temp or app data). Similar to the 2nd bullet but then maybe we'll be a bit more consistent than just doing things for different OS's.

Any thoughts/opinions on these 3 points?

[rjmholt]

Well my thinking is:

• We should try to behave as a subordinate to VSCode and try to live within its established areas. We're a plugin, not a standalone application, and we're only going to annoy users if we start carving out new parts of the hard drive for ourselves.
• But, clearly doing everything in the VSCode extensions folder doesn't work due to permissions. Cleaning that folder out periodically would also address the root problem here maybe, but really users should have full access to the logs of their sessions, especially because they're mainly needed to send to us when things go wrong. Quietly erasing the logs every interval could make issues much harder to diagnose.
• A platform-specific solution is more complex, but VSCode and PowerShell already do a lot of platform-specific things in the interest of doing the right thing on the platform while keeping the user an abstraction layer above. That's the ecosystem we live in.
• It might be that using a temp directory might be more fraught than it first appears: Provide a platform-agnostic way to determine the temp. directory, e.g., via an automatic variable. PowerShell#4216, /tmp vs /var/tmp, TMPDIR vs other options on macOS. Basically there are a lot of loose rules on temporary directories, and they are more platform-specific, not less.

So my personal preference would be to use:

• A common, VSCode-subordinate log path, OR
• A conventional application log file:
  • %APPDATA% on Windows;
  • /Users/<user>/Library/Application Support/ on macOS;
  • $HOME/.vscode or similar on Linux

[yume-chan]

@rjmholt

writing logs to the system temp directory would make us a bit unusual as an application.

At least I think writing logs to your applications' "installation location" (for extensions, isn't the vscode extension folder their home?) is more unusual.

It makes sense to clean out the logs, but I feel like it should be up to you as a user, not an implementation detail of your host OS.

I personally feel comfortable when the OS can clean my unneeded files automatically. Applications should be more consistent with the OS, even if it means they will work differently on different OSs. I know it's cross-platform, but I don't think it should re-invent the wheel to create another self-styled behavior.

One more merit to use the temp folder:

Code is adding support for portable mode, ideally all extensions should follow and don't leave any file on the host machine.

Code will write the temp folder path into TEMP(win32) or TMPDIR(other) environment variable, so the easiest way should be always reading from these environment variables.

(I assume this environment variable will also be set for the extension host process, but I haven't try it. So if I'm wrong, please point me out)

EDIT: I know, and agree that temp folder is not a suitable path for logs, but at least it's easy to use. If it's not easily accessible for the user, the extension can create their own log folder in the temp folder, then add a command to quickly open it for the user.

[rjmholt]

At least I think writing logs to your applications' "installation location" (for extensions, isn't the vscode extension folder their home?) is more unusual.

Agreed there - I'm suggesting we should consider writing logs to conventional application data folders instead. Not saying I'm against writing to a temp folder, just want to make it clear that I wasn't saying we should write to the install location -- in fact I think we shouldn't do that.

[rjmholt]

A couple of notes on the temp folder situation:

• %TEMP%/$env:TEMP works well on Windows (and also happens to be under %APPDATA%).
• $TMPDIR exists on macOS, but is randomly generated. The one on my machine right now is at /var/folders/jx/qs_zdfg95_1gkf70pn7nrb7h0000gn/T/, and I think it changes on startup.
• None of $TMP, $TEMP or $TMPDIR is defined on Ubuntu 16.04 (the machine I've got with me), and it looks like those variables can't be relied on in general on Linux. So there we'd want to use something like /tmp or /var/tmp.