FS#74342 - [lua-language-server] Place tmpfiles under parent directory
Attached to Project:
Community Packages
Opened by Adrian (adrian5) - Monday, 04 April 2022, 12:04 GMT
Last edited by Daniel M. Capella (polyzen) - Friday, 14 July 2023, 22:56 GMT
Opened by Adrian (adrian5) - Monday, 04 April 2022, 12:04 GMT
Last edited by Daniel M. Capella (polyzen) - Friday, 14 July 2023, 22:56 GMT
|
Details
Currently every start of the server adds a temporary
directory to `/tmp`. I find that in daily use this quick
pollutes the directory with lots of instances, since it
doesn't clean up after itself.
I'd prefer if the `/usr/bin/lua-language/server` startup script placed them under a parent directory, i.e. mkdir /tmp/lua-language-server TMPPATH=$(mktemp -d "/tmp/lua-language-server/instance.XXXX") Then it can grow ad infinitum hidden within that directory. |
This task depends upon
Closed by Daniel M. Capella (polyzen)
Friday, 14 July 2023, 22:56 GMT
Reason for closing: Implemented
Additional comments about closing: 3.6.23-2
Friday, 14 July 2023, 22:56 GMT
Reason for closing: Implemented
Additional comments about closing: 3.6.23-2
`mkdir -p /tmp/lua-language-server` is probably better in the above snippet.
1. The current directory choice appears to be Arch-specific, not application defaults we'd diverge from.
2. Even if a cleanup option existed, it may not be wise to hardcode it, as users may want logs.
With a simple change, everything is contained in an application specific directory:
mkdir -p /tmp/lua-language-server # Create common dir for language server runtime output
TMPPATH=$(mktemp -d "/tmp/lua-language-server/instance.XXX") # Nest instances within dir
What's the downside?
This is actually common among a number of distros. Can't remember where it originated.
/tmp/instance.oPt
/tmp/instance.nNx
/tmp/instance.rrK
/tmp/instance.FWe
…
And while some people consider /tmp to be a garbage heap, I'm not aware of any other applications that pollute the dir like that. This has happened (e.g. with lockfiles) but ends up getting fixed.
No, just a clarification.