D17289: KDevelop/Shell: set dedicated TMPDIR

Aaron Puchert noreply at phabricator.kde.org
Thu Jan 24 23:23:14 GMT 2019


aaronpuchert added a comment.


  In D17289#399019 <https://phabricator.kde.org/D17289#399019>, @rjvbb wrote:
  
  > > If you don't use systemd, for example because you're not on Linux, there are certainly other tools for doing the same thing.
  >
  > How does that systemd thing clean tmp dirs at runtime, IOW, how can it know it's safe to clean up a given file if the application that created it doesn't do something explicit to guarantee cleanup?
  
  
  Of course it can't technically know if it is safe to delete a file. The assumption is that if it hasn't been used in a long time, it's probably not needed anymore. There is a configurable age parameter, set to a few days/weeks usually. “The age of a file system entry is determined from its last modification timestamp (mtime), its last access timestamp (atime), and (except for directories) its last status change timestamp (ctime). Any of these three (or two) values will prevent cleanup if it is more recent than the current time minus the age field.”
  
  There is also tmpwatch <https://linux.die.net/man/8/tmpwatch> which allows restricting the cleanup to files that are no longer open. It seems that systemd doesn't offer this because it's too slow and shouldn't be needed <https://access.redhat.com/solutions/2078313>.
  
  I know that Windows also has a disk cleanup program. There is an article <http://osxdaily.com/2016/01/13/delete-temporary-items-private-var-folders-mac-os-x/> claiming that the only way to clean up temporary files on Mac is a reboot.
  
  > 
  > 
  >> a way to reset `TMP_DIR` for childs that doesn't introduce race conditions.
  > 
  > How could this be a race condition?
  
  I was referring to @mwolff's comment D17289#395163 <https://phabricator.kde.org/D17289#395163>.
  
  > I'd be fine with that if libclang never left its big pch files behind even on a clean exit.
  
  Well, maybe you can solve that instead? Perhaps we're using it wrong, or there is a bug in Clang.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D17289

To: rjvbb, #kdevelop, kfunk, mwolff
Cc: aaronpuchert, mwolff, pino, kfunk, kdevelop-devel, glebaccon, hase, antismap, iodelay, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20190124/5b6f6cbe/attachment.html>


More information about the KDevelop-devel mailing list