Saving your $HOME space

Posted Jan 8, 2009 6:39 UTC (Thu) by eru (subscriber, #2753)
Parent article: BleachBit: Does GNU/Linux need the equivalent of a Windows registry cleaner?

you have to wonder whether the minimal disk spaced saved or the privacy gained by running it is worth the effort

Unfortunately, several programs love to stash large amounts of cached data in their dot-directories under your home directory, so it is not always a minimal disk space we are talking about!

I have always found the use of $HOME for caching very annoying. It is wasting "prime real estate", because the home is usually backed-up (or at least more likely to be backed-up than other parts of the file system), and in many cases (especially in corporate environments) it is on a network file system (so using it for a browser cache just increases network traffic). Why cannot all apps use put their caches on /var/tmp or some such? Some already do.

Saving your $HOME space

Posted Jan 8, 2009 11:29 UTC (Thu) by rwmj (subscriber, #5474) [Link] (10 responses)

Coming from an application developer's point of view, the reason is that it's very easy to stash stuff in the home directory. It's usually nothing more than getenv ("HOME") followed by creating a dot-file or subdirectory. You know the data will still be there next time the application is launched (even across reboots or long delays), and you know there won't be any security issues or conflicts as can arise when you use /var/tmp.

What to do about it? I think you've identified a new class of storage: Per-user. Temporary in that it can be deleted at any time. But persistent in that the OS should keep it around as long as possible.

With a new class of storage should come a new location. Something like $HOME/.tmp/, where applications can store this cached data, but if space is tight the OS may remove it (eg. at boot) without repercussions.

Rich.

Saving your $HOME space

Posted Jan 8, 2009 12:43 UTC (Thu) by eru (subscriber, #2753) [Link] (9 responses)

More precisely, can be deleted any time the user does not have a "session" on the machine. It would lead to bugs if applications would have to test if the data is still there while they are running.

With a new class of storage should come a new location. Something like $HOME/.tmp/, where applications can store this cached data, but if space is tight the OS may remove it (eg. at boot) without repercussions.

Not under $HOME, please. As I noted, it is often backed-up and/or non-local storage (in some cases even a USB stick), and should not be wasted for caching. A convention like /var/tmp/caches/$USER would be preferable. If the convention were commonly used, standard library functions could be added to make a sub-directory under this user cache in a secure way, making usage as easy for application writers as using the $HOME directory.

Saving your $HOME space

Posted Jan 9, 2009 4:30 UTC (Fri) by k8to (guest, #15413) [Link] (3 responses)

There should be a per-user tmp, and the global tmp should be rarely, if ever, used.

I have no idea why we ever had a global tmp for most purposes. Laziness, I suppose.

Saving your $HOME space

Posted Jan 10, 2009 14:09 UTC (Sat) by epa (subscriber, #39769) [Link] (2 responses)

Yes, given the ridiculous frequency of /tmp-race security holes, and the negligable performance difference for most apps, $HOME/tmp should be the default. It can be a symlink to /tmp/me for people who still insist on a separate /tmp partition for whatever reason.

Saving your $HOME space

Posted Jan 10, 2009 14:45 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

You want pam_mount and a user-specific directory, really. You can still
*mount* it on /tmp...

Saving your $HOME space

Posted Feb 16, 2009 22:06 UTC (Mon) by k8to (guest, #15413) [Link]

For tradition, at least, /tmp should be global. I don't watnt to break any programs that rely on existing functionality. At least, that's how I'd do it on my systems.

Saving your $HOME space

Posted Jan 9, 2009 21:08 UTC (Fri) by felixrabe (guest, #50514) [Link] (1 responses)

Omit the offending subdirectory during backup. Piece of cake with rsync.

Saving your $HOME space

Posted Jan 11, 2009 19:56 UTC (Sun) by eru (subscriber, #2753) [Link]

Omit the offending subdirectory during backup. Piece of cake with rsync

But not always with other backup methods. In fact, in a corporate environment you may not have any control over how the backup is made. And this still does not address the inherent inefficiency of using a network directory or USB stick for temporary storage. No, the cache directory really must be somewhere else than $HOME.

Keep my data in my $HOME

Posted Jan 12, 2009 7:48 UTC (Mon) by rvfh (guest, #31018) [Link] (2 responses)

What's the big difference between using /var/.../%USER and /tmp or /var/tmp ?

I'd rather all user data were stored in their home, which may be encrypted rather than on some random part of the file system like /var/mail or /tmp...

I wish all files belonging to me (and therefore potentially personal and confidential) were in my $HOME where they belong.

So yes, $HOME/.tmp is a possibility , or just $HOME/.$appname/... back to square one.

At the end of the day, we have to rely on the app not making stupid use of our space, and can't do much about it appart from complaining and patching. It's Free Software after all!

Keep my data in my $HOME

Posted Jan 12, 2009 8:37 UTC (Mon) by nix (subscriber, #2304) [Link]

On my systems, /home is a) NFS-mounted, b) a RAID array, c) shared across
hosts. These are all undesirable things for /tmp, but desirable for home
directories.

/tmp should not be under /home.

Keep my data in my $HOME

Posted Jan 14, 2009 15:25 UTC (Wed) by nlucas (guest, #33793) [Link]

Note that "/tmp" and "/var/tmp" have different functions.

"/tmp" is for temporary files that can be completely cleaned up on system reboot (and many distros have init scripts that do exactly this).

"/var/tmp" is for temporary files that are to be preserved between reboots.

Google for FHS for more information.