On Wed, Jan 20, 2016 at 09:17:10AM +0100, Martin Pitt wrote:
> By far the most common reason that I've seen is that files are the
> Unix way for exchanging little pieces of data with other programs,
> like flag files, named pipes, Unix sockets, editors, or in general
> things you need to call external programs on. I think the latter is
> what you meant as well with b). But in all but corner cases these are
> tiny. And in these corner cases it doesn't really matter much whether
> your program overflows RAM or your root partition -- it's buggy and
> needs to be fixed, or as a user you just tried to do something
> unreasonable which your computer is too small to do.
One real example I know of is debdiff, which can generate quite large
files in /tmp during operation, but cleans them up afterwards.
Depending on the packages you're working with - let's say kernel
packages, for example - they can quite easily be in the sort of
few-gigabytes range that would be troublesome if it means evicting the
corresponding amount of working set from other processes or pushing you
into swap, but not a problem at all for disk use. It honours TMPDIR so
can be made to point somewhere else (nowadays, Launchpad sets TMPDIR
when invoking debdiff in order that it can reliably clean things up even
if debdiff dies), but still a bit of a surprise if you weren't expecting
it.
It wouldn't surprise me to find quite a few odds and ends of development
tools that do this kind of thing, and whether it's a practical problem
for you will depend on the sorts of sizes of trees you typically work
with.
--
Colin Watson [cjwatson@ubuntu.com]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
