[vim/vim] Implement a cross-platform way to get the OS cache dir (PR #10193)
LemonBoy
Borrow the name from NeoVim's stdpath() but handle only a single case,
"cache". If needed this function can be easily expanded to handle more
cases and, if the XDG specification is ever adopted, to return some
sensible values for other kind of data beside cached files.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/10193
Commit Summary
- 2aa6c76 Implement a cross-platform way to get the OS cache dir
File Changes
(10 files)
- M runtime/doc/builtin.txt (11)
- M src/errors.h (2)
- M src/evalfunc.c (37)
- M src/os_macosx.m (11)
- M src/os_unix.c (13)
- M src/os_win32.c (11)
- M src/proto/os_unix.pro (1)
- M src/proto/os_win32.pro (1)
- M src/testdir/test_functions.vim (19)
- M src/vim.h (3)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
LemonBoy
@LemonBoy pushed 1 commit.
- 5a049f2 Implement a cross-platform way to get the OS cache dir
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
codecov[bot]
Codecov Report
Merging #10193 (5a2abae) into master (eca7c60) will decrease coverage by
1.05%.
The diff coverage is60.00%.
@@ Coverage Diff @@ ## master #10193 +/- ## ========================================== - Coverage 81.98% 80.92% -1.06% ========================================== Files 167 152 -15 Lines 187927 175105 -12822 Branches 42378 39723 -2655 ========================================== - Hits 154073 141706 -12367 + Misses 21505 20747 -758 - Partials 12349 12652 +303
| Flag | Coverage Δ | |
|---|---|---|
| huge-clang-none | 82.39% <60.00%> (-0.02%) |
⬇️ |
| huge-gcc-none | ? |
|
| huge-gcc-testgui | ? |
|
| huge-gcc-unittests | 2.00% <0.00%> (-0.01%) |
⬇️ |
| linux | 80.92% <60.00%> (-3.06%) |
⬇️ |
| mingw-x64-HUGE | ? |
|
| mingw-x64-HUGE-gui | ? |
|
| windows | ? |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/os_unix.c | 66.37% <33.33%> (-2.12%) |
⬇️ |
| src/evalfunc.c | 88.14% <71.42%> (-2.73%) |
⬇️ |
| src/libvterm/src/rect.h | 0.00% <0.00%> (-96.78%) |
⬇️ |
| src/libvterm/src/state.c | 34.80% <0.00%> (-54.83%) |
⬇️ |
| src/libvterm/src/keyboard.c | 40.00% <0.00%> (-47.63%) |
⬇️ |
| src/libvterm/include/vterm.h | 0.00% <0.00%> (-44.45%) |
⬇️ |
| src/libvterm/src/parser.c | 55.41% <0.00%> (-40.49%) |
⬇️ |
| src/libvterm/src/pen.c | 44.37% <0.00%> (-39.90%) |
⬇️ |
| src/libvterm/src/encoding.c | 37.37% <0.00%> (-36.16%) |
⬇️ |
| src/libvterm/src/vterm.c | 39.17% <0.00%> (-27.21%) |
⬇️ |
| ... and 148 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered by Codecov. Last update eca7c60...5a2abae. Read the comment docs.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
So the XDG standard specifies this as " user-specific non-essential (cached) data ". What does that mean?
No idea what to use it for. Does "non-essential" mean it can disappear any moment?
Does "user-specific" mean other users cannot access it? Or can they?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
LemonBoy
Does "non-essential" mean it can disappear any moment?
It only means the data is not essential for the program to work, if the cache is purged the application will populate it again.
Does "user-specific" mean other users cannot access it? Or can they?
"user-specific" opposed to "system-wide". Think of it as a local, per-user, /var/cache.
The specification doesn't say anything about permissions.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
This sounds rather unreliable. I can see that my ~/.cache directory isn't cleared on reboot, thus files are catching dust there, nobody ever cleans it up. And if someone has a script running to avoid that, it means files can disappear "under your fingers".
And different systems may have different behavior, since the standard doesn't say anything.
Oh, and it looks like my cache directory is readable by the group but not other users. Thus it can't be used to share files with other users.
This appears to need a "use at your own risk" warning.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
LemonBoy
Oh, and it looks like my cache directory is readable by the group but not other users. Thus it can't be used to share files with other users.
That's where the user-specific part comes into play.
This appears to need a "use at your own risk" warning.
It doesn't seem to me that the current documentation is promising more than it is delivering, stdpath is all about giving the user a sensible default to avoid getting lost in a maze of if has (and having to handle all the different cases) or hardcoding some paths that may or may not make too much sense.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > Oh, and it looks like my cache directory is readable by the group
> > but not other users. Thus it can't be used to share files with other
> > users.
>
>
> > This appears to need a "use at your own risk" warning.
>
> It doesn't seem to me that the current documentation is promising more
> than it is delivering, `stdpath` is all about giving the user a
> sensible default to avoid getting lost in a maze of `if has` (and
> having to handle all the different cases) or hardcoding some paths
> that may or may not make too much sense.
cannot be sure how it can be used. It should state some things like:
- Only accessible by the current user.
- Will survive a system reboot.
- Files are removed only when intentionally cleaning up, no expiry date.
Other problems are name clashes, how does one make sure that the files
created there are not colliding with other applications?
Is there anything said about the size of the files that can be stored?
How does one prevent the files stored there continuously growing (I
actually had to manually inspect ~/.cache and remove stuff from an app I
used only once almost a year ago).
All these questions make such a path totally useless.
--
Engineers understand that their appearance only bothers other people and
therefore it is not worth optimizing.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I am a bit confused. What do we need the cache directory for? Can you please clarify, what Vim would use the cache dir for? Swapfiles? Undofiles? vimrc? Others?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
LemonBoy
I am a bit confused. What do we need the cache directory for? Can you please clarify, what Vim would use the cache dir for? Swapfiles? Undofiles? vimrc? Others?
Often plugins need a safe place to store their cached data (eg. think of some language servers, plugins downloading data from internet, plugins preprocessing a lot of data in a more manageable format) or, as you mentioned, users (like me) may find this useful to choose where to store the swapfiles/undofiles.
My point is that without specifying the properties of the directory, one
cannot be sure how it can be used. It should state some things like:
- Only accessible by the current user.
- Will survive a system reboot.
- Files are removed only when intentionally cleaning up, no expiry date.
None of this can be enforced at any level, if the user sets up this folder on a ramdisk or has a script to periodically remove the content we can't do much. Given the implementation of stdpath we can pull this argument inside-out: we're using the path that, according to the OS/DE, applications are supposed to use for this kind of data. The burden of respecting this contract is definitely not on Vim.
Other problems are name clashes, how does one make sure that the files
created there are not colliding with other applications?
You can't, the same way you can't provide any guarantee about the unicity of temporary files. We could append a /vim at the end so that the base path becomes something like ~/.cache/vim/ and introduce this "namespace".
Is there anything said about the size of the files that can be stored?
How does one prevent the files stored there continuously growing (I
actually had to manually inspect ~/.cache and remove stuff from an app I
used only once almost a year ago).
This is definitely off-topic and a rant about the general state of the OS mechanism to store cached/temporary data.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > I am a bit confused. What do we need the cache directory for? Can
> > you please clarify, what Vim would use the cache dir for? Swapfiles?
> > Undofiles? vimrc? Others?
>
> Often plugins need a safe place to store their cached data (eg. think
> of some language servers, plugins downloading data from internet,
> plugins preprocessing a lot of data in a more manageable format) or,
> as you mentioned, users (like me) may find this useful to choose where
> to store the swapfiles/undofiles.
cache directory. Files there could be deleted any moment, thus you
should not store an undo file there. A swapfile gone missing will also
cause trouble, you can't always re-create it.
This is exactly the problem with offering a path without specifying
exactly how it can be used.
> > My point is that without specifying the properties of the directory, one
> > cannot be sure how it can be used. It should state some things like:
> > - Will survive a system reboot.
> > - Files are removed only when intentionally cleaning up, no expiry date.
>
> None of this can be enforced at any level, if the user sets up this
> folder on a ramdisk or has a script to periodically remove the content
> we can't do much. Given the implementation of `stdpath` we can pull
> this argument inside-out: we're using the path that, according to the
> OS/DE, applications are supposed to use for this kind of data. The
> burden of respecting this contract is definitely not on Vim.
If we would say that for Unix it's the ~/.cache directory, then at least
the user has some clue what it means (only readable by the user and the
group, will survive a system crash, won't be cleared automatically
unless you have setup something for that).
If the directory comes from $XDG_CACHE_HOME I have no clue. Will it be
cleared on system restart or not? Can the group access it? It does
state it's for private use, but does that guarantee other users can't
access it?
> > Other problems are name clashes, how does one make sure that the files
> > created there are not colliding with other applications?
>
> You can't, the same way you can't provide any guarantee about the
> unicity of temporary files. We could append a `/vim` at the end so
> that the base path becomes something like `~/.cache/vim/` and
> introduce this "namespace".
guaranteed to be unique and private.
> > Is there anything said about the size of the files that can be stored?
> > How does one prevent the files stored there continuously growing (I
> > actually had to manually inspect ~/.cache and remove stuff from an app I
> > used only once almost a year ago).
>
> This is definitely off-topic and a rant about the general state of the
> OS mechanism to store cached/temporary data.
we must also specify how to get rid of them. I don't know how many
people have complained about swap files laying around.
--
If they don't keep on exercising their lips, he thought, their brains
start working.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
LemonBoy
Closed #10193.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.