Fix resource locations in FAQ
Needs ReviewPublic

Authored by citelao on Feb 3 2019, 4:45 AM.

Details

Reviewers
rempt
Group Reviewers
Krita: Manual
Summary

The resource locations on the Krita FAQ for Windows were incorrect in places and confusing to read in others (unclear hierarchy, etc).

I updated the locations to be correct:

  • %APPDATA%/Local would be %USERPROFILE%/AppData/Roaming/Local (see the end of the docs for KNOWNFOLDERID). I corrected this to %LOCALAPPDATA%.
  • I did some testing (created a Resource Pack, Brush Preset, and a Brush Tip), and the Windows Store version seems to still save to %APPDATA%/Krita, so I removed the "Windows Store" note there.
  • I added a reference to the actual source of the string---"Package Family Name." I'm not too familiar with UWP packaging, but does this remain the same? Could the docs just include the full string?

Thanks! This is my first PR; let me know if I need to update anything. I would like attribution; not sure if I need to do anything special there :). Also, I cannot build this on my PC (no Python); let me know if I should test myself.

Diff Detail

Repository
R1012 Krita.org Documentation Website
Lint
Lint Skipped
Unit
Unit Tests Skipped
citelao created this revision.Feb 3 2019, 4:45 AM
Restricted Application added a project: Krita: Manual. · View Herald TranscriptFeb 3 2019, 4:45 AM
Restricted Application added a reviewer: Krita: Manual. · View Herald Transcript
citelao requested review of this revision.Feb 3 2019, 4:45 AM
woltherav added a subscriber: woltherav.

Hm... Boud needs to check if these are correct first.

Actually, as far as I can tell, Krita is still using %LOCALAPPDATA%\kritarc even in the Store version. Could this be because I installed without the Store first?

See https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-behind-the-scenes#file-system

In order to contain app state, changes that the application makes to AppData are captured. All write to the user's AppData folder (e.g., C:\Users\user_name\AppData), including create, delete, and update, are copied on write to a private per-user, per-app location. This creates the illusion that the packaged application is editing the real AppData when it is actually modifying a private copy. By redirecting writes this way, the system can track all file modifications made by the app. This allows the system to clean up those files when the application is uninstalled, thus reducing system "rot" and providing a better application removal experience for the user.

The wording here seems to imply that the modifications to the actual AppData directories would still be written there, but reverted when the app is uninstalled? I can't understand how it would work though, since other processes can also modify those files. It's especially confusing if one have both the Store version and the installer/portable versions set up side-by-side.

It also probably differs whether the application files are already there before the Store version gets installed.

citelao added a comment.EditedFeb 3 2019, 10:24 PM

It also probably differs whether the application files are already there before the Store version gets installed

I did some trials (listed below), and it looks like Krita behaves as described in the documentation you linked for kritadisplayrc and behaves differently for kritarc and kritashortcutsrc:

  1. If file exists in redirected location, use that for reads and writes.
  2. Otherwise, if file exists in %LOCALAPPDATA%, use that for reads and writes.
  3. Otherwise, create the file in redirected location and use that.

Kritarc

  1. Move my %LOCALAPPDATA%/kritarc to kritarc.bak.
  2. Open Krita. Krita created a kritarc file in the redirected location (Packages/.../LocalCache/Local).
  3. Change theme. The redirected file changes and the original one does not.
  4. Close Krita.
  5. Rename %LOCALAPPDATA%/kritarc.bak back to its original name.
  6. Relaunch Krita. Krita still has the changed theme from the redirected location and does not update the %LOCALAPPDATA%/kritarc.
  7. Close Krita.
  8. Delete the redirected kritarc.
  9. Relaunch Krita. Krita now defers to the original non-redirected file.
  10. Change theme. Krita updates the non-redirected file. It does not copy-on-write.

Kritashortcutrc and kritadisplayrc

  1. Copy redirected kritashortcutrc into %LOCALAPPDATA%.
  2. Rename the redirected kritashortcutrc to kritashortcutrc.bak.
  3. Launch Krita.
  4. Change a shortcut. Krita updates the non-redirected kritashortcutrc and does not create a redirected one.
  5. Perform 1-3 for kritadisplayrc.
  6. Change HiDPI mode. Krita creates a new redirected kritadisplayrc and does not use the non-redirected one.

Does this make sense?

rempt accepted this revision.Feb 6 2019, 11:01 AM

For attribution, we will need your name and email address.

This revision is now accepted and ready to land.Feb 6 2019, 11:01 AM
citelao requested review of this revision.Feb 9 2019, 3:04 AM

For attribution, we will need your name and email address.

My name is my profile—Ben Stolovitz—and my email is ben@stolovitz.com.

But: since Krita isn't behaving according to the sandboxing documentation linked earlier, I'm not comfortable saying this should be signed off.

Can you point me in the right direction to either:

  • discuss what Krita *should* be doing
  • examine the code to figure out why Krita *is* doing what it is

No matter what, this diff needs to change (since it should clarify that Krita uses the non-sandbox locations in most cases).

Thanks!

rempt added a comment.Feb 9 2019, 10:30 AM

The thing is, Krita from the Windows Store is the same binary as we make available on the krita.org website. We put it through the DAC to create the appx, and don't do anything special whatsoever. We don't even have our own code to find the locations to store user and application data: that's all handled by https://doc.qt.io/qt-5/qstandardpaths.html

Does this make sense?

No, just like 90% of the rest of Windows.

However, on my system where I use the desktop version, after installing and running the Store version I get a copy of the existing Krita resource files (basically the whole tree of %localappdata%\krita) in the redirected location (even the "last modified" timestamps are the same). The config files are also written in the redirected location. Though I can't verify whether it has modified anything in the original locations.

I think your test may be flawed.

(Unrelated note: I do however see several kritadisplayrc.****** files popping up in the redirected location. This is probably QSaveFile failing to delete the temp file.)

But: since Krita isn't behaving according to the sandboxing documentation linked earlier, I'm not comfortable saying this should be signed off.

Can you point me in the right direction to either:

  • discuss what Krita *should* be doing
  • examine the code to figure out why Krita *is* doing what it is

    No matter what, this diff needs to change (since it should clarify that Krita uses the non-sandbox locations in most cases).

    Thanks!

For this case I wouldn't say Krita is really doing anything wrong. Every config files and resources are written under AppData (either Roaming or Local) and it's the job of Desktop Bridge to properly handle the file redirection. To me it doesn't look like the Store version would be modifying the files in the original AppData locations.

By the way, you should refrain from calling it "sandbox" since it is merely a form of file redirection without full sandboxing.

[...]

However, on my system where I use the desktop version, after installing and running the Store version I get a copy of the existing Krita resource files (basically the whole tree of %localappdata%\krita) in the redirected location (even the "last modified" timestamps are the same). The config files are also written in the redirected location. Though I can't verify whether it has modified anything in the original locations.

I think your test may be flawed.

(Unrelated note: I do however see several kritadisplayrc.****** files popping up in the redirected location. This is probably QSaveFile failing to delete the temp file.)

[...]

Hello again!

I finally re-ran my tests and got the same results I mentioned above (which differ from yours). Detailed below.

My guess is I've found a Windows bug :). I'll see if I can get any information about this issue.

Thanks all!

Tests

No files

  1. Krita off.
  2. Rename any existing files to .bak:
    • %localappdata%/kritarc
    • %localappdata%/kritadisplayrc
    • %localappdata%/krita
  3. Open Krita.
  4. Settings > Configure Krita...
  5. Keyboard Shortcuts > Say Hello World > _
  6. General > Window > Window Background > red
  7. OK
  8. Close Krita.
Results
  • No Krita files whatsoever in %localappdata%.
  • %localappdata%\Packages\49800KritaProject.Krita_n3kgb906j1zjg\LocalCache\Local had:
    • krita/ (updated slightly before the others)
    • kritadisplayrc
    • kritarc
    • kritashortcutrc

Rewrite the redirected directory?

[... tried renaming %localappdata%\Packages\49800KritaProject.Krita_n3kgb906j1zjg\LocalCache\Local to Local.bak, which ended up writing to %localappdata%]

  1. Delete newly created %localappdata% files [from the experiment I left out].
  2. Create Local directory: %localappdata%\Packages\49800KritaProject.Krita_n3kgb906j1zjg\LocalCache\Local
  3. Open Krita.
  4. Settings > Configure Krita...
  5. Keyboard Shortcuts > Say Hello World > _
  6. General > Window > Window Background > red
  7. Ok
  8. Close Krita.
Results
  • No files created in %localappdata%
  • Krita Packages/ subdirectory gets new files:
    • kritadisplayrc (first)
    • krita/ (second)
    • kritarc (third)
    • kritashortcutrc (after changing shortcut)

Which files take precedence?

  1. Rename %localappdata%/kritarc.bak to kritarc.
  2. Launch Krita.
  3. Settings > Configure Krita
  4. General > Window > Window Background. Observe it is "red."
  5. Change it to Aqua. Observe that all Packages/ files change, but %localappdata% do not.
  6. Close Krita.
  7. Rename Packages/ kritarc to kritarc.bak.
  8. Launch Krita.
  9. Settings > Configure Krita
  10. General > Window > Window Background. Observe it is "grey," the value of %localappdata%'s copy.
  11. Keyboard Shortcuts > Say Hello World. Observe it is still _.
  12. Set Window Background to dark blue. Observe %localappdata%/kritarc changes.