Place logdir under user's Documents folder on Windows

[victoryforce]

Rationale of this change is in #17141 (comment).

I copy the relevant text to the following paragraphs.

Existing problems:

• The log is somewhere deep in the tree of the apps working directories (AppData), where the user never looks, so it is impossible to come across it without knowing the exact location
• The log file is located under a directory that is hidden, so with the default system settings, it cannot be accessed by navigating in File Explorer. It is necessary to either teach the user to change the Windows setting to "show hidden files", or explain that the path they were told must be entered in the address field.

The following is proposed as a solution:

• Placing the log in a more visible and easily accessible location, for example under the Documents directory.

This PR implements the proposed solution.

I was considering putting the logging directory one level up, ie in %USERPROFILE% instead of %USERPROFILE%\Documents.
However, I don't think it will be any better. Standard user profile folders (such as Desktop, Documents, Pictures etc) are directly accessible in File Explorer, while going to %USERPROFILE% requires more clicks.

Also, for example, Adobe creates a folder of the same name in Documents. DxO PhotoLab also places folder for log files there.

Regarding folder name capitalization. We already have default import session base directory as $(PICTURES_FOLDER)/Darktable. So the folder for log files is also named Darktable with capital first letter for consistency.

[TurboGit]

Fine by me, thanks!

[kmilos]

Sorry for not paying attention to this earlier...

I don't think this is a good idea - Documents is typically synced to OneDrive on Windows OOTB and creating stuff there without the user's knowledge is IMHO bad form. On top of that we know that trying to write to files while they're syncing is problematic...

I feel your alternative of %USERPROFILE%\Darktable might actually be better, although it really doesn't seem many apps do something like that (there are cross-platform FLOSS apps that create %USERPROFILE%\.foo or even %USERPROFILE%\.config\bar).

[victoryforce]

creating stuff there without the user's knowledge is IMHO bad form.

It's right in front of the user's eyes in a folder that the user often uses, how can you claim it's "without the user's knowledge"?

In top of that we know that trying to write to files while they're syncing is problematic...

This is a very strange statement. OneDrive may not be syncing a file because it's open and in use by another application. What is problematic about this? This is completely obvious behavior and it will also apply to a document that I have open and editing while it is syncing. The file that darktable writes to is no different from the one I work with. There is no need to scare us with this.

[kmilos]

how can you claim it's "without the user's knowledge"?

You're committing them to uploading something to their cloud storage that maybe they preferred not to have there, and maybe they're not aware of this straight away.

What is problematic about this?

We've had multiple bug reports of exported JPEGs missing metadata when the exported folder (%USERPROFILE%\Pictures\Darktable) is synced to OneDrive because export is a two step process: JPEG gets created first w/o metadata, then it immediately starts syncing and gets locked by OneDrive, and then dt in the second step via exiv2 cannot reopen it to add metadata. But perhaps it's not such a problem here as you're not closing/releasing the log file in the meantime...? Corner case is relaunching dt sessions too quickly on a slow network?

[parafin]

Just an idea - how about moving log file back to original path and instead placing a shortcut (perhaps by installer?) to that location into Documents folder?

[Macchiato17]

As I was not aware of this PR 😉, I recently started a topic in the pixls.us discussion group, since I haven't found the debug log anymore... I was asked to add my 2ct to this PR discussion, so I just copy my suggestions and thoughts here:

So from my point of view, the documents folder is a little unexpected here, as was the INetCache directory before. While the first is intended for user documents (Word, etc.), the latter is used for temporary internet files.
AppData is the location of choice when storing configuration and program specific user data, so I would vote for the darktable profile folder which is already located at the non-roaming application data at C:\Users\<userName>\AppData\Local\darktable, i.e. %localappdata%\darktable (when referencing Windows path variables) and therefore the best bet.
An alternative and also expected path would be the %temp% path, i.e. C:\Users\<userName>\AppData\Local\Temp or %localappdata%\Temp.

[victoryforce]

I would like to emphasize from the very beginning that I carefully considered where to place the log files directory and compared different options. I believe that placing it under Documents is the most convenient for the user and will not create any problems.

It's very strange that OneDrive's default settings were mentioned as an argument against. I didn't expect that. Even if the user does not change the default settings of OneDrive (and such users, as a rule, simply do not use it, otherwise they would adjust it to their needs), I do not see anything wrong:

• Files in the Documents folder do not have to be static. Some of them are edited by the user. Sorry, but "we know that trying to write to files while they're syncing is problematic..." cannot be true. If it were so, then the user would constantly have problems when working with files in Documents, which is not the case.
  Writing to a file locks it and the synchronization process will be forced to skip this file. That's all.

• You should not worry that the log file will be synchronized on OneDrive, if the user does not want to configure the synchronization of only folders worth backing up. Why should we worry about a user who doesn't care?

• I already wrote in a comment that Adobe and DxO Labs made a similar decision to place their subdirectories under Documents. In addition, DxO PhotoLab writes the log there, that is, it is completely our case. I don't see how darktable will allegedly have problems with this, and the products of these companies will not.

Oh, and by the way, another product in my system, this time not related to image processing. The ShareX screenshot tool places all data related to its work in Documents\ShareX (screenshots, settings, logs, backups).

[Macchiato17]

Please don't get me wrong. I appreciate your contribution and your effort to change the folder location. And I have no doubt that you carefully considered your proposal. No need to justify yourself, if you have such feeling because of my feedback. Since I was a little puzzled concerning the new path (as I tried to describe in my comment) and I was asked to put my suggestion here, I did it.

From my understanding, the documents folder simply has a different role / semantics. I would not expect an application (debug) log file there, as it is an output from the application itself, a kind of "application noise" and no work generated by the user. The latter I may well expect in such folder.

My suggestion follows my experience and what Microsoft explains in their developer guides (see https://learn.microsoft.com/en-us/windows/win32/shell/csidl or https://learn.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-8.0 as an example). There are a lot of applications, even developed by large companies, that do it their way, but not necessarily according to the recommendation,..

So for me anything is fine, I will stop commenting this PR, as I have no stakes at all. I just wanted to give some input. Do it like you want, as long as the user is able to find the output.

Best regards.

[victoryforce]

@TurboGit My proposal for the release notes:

• The directory where darktable will write the log file under Windows has been changed to %USERPROFILE%\Documents\Darktable. This allows the user to easily see where the log file is located without even having to search for it in the documentation or FAQ. The previous location was deep in the system subdirectories of the user profile, and also under a hidden directory (so it was impossible to click to it in File Explorer with default system settings).

This is a lengthy description, shorten it if you think it's better.

Also, it would certainly be best if this information wasn't buried somewhere deep in the release notes, although I understand that this change is definitely not The Big Ones. :)

[TurboGit]

Thanks! For now I append entries at the end of the corresponding section. We can edit later.

[victoryforce]

We don't document the location of the application log in Windows anywhere in the user manual. This information is in the FAQ on darktable.org, where it has already been updated in a PR darktable-org/dtorg#259.

So I'm removing the documentation-pending label.