On 20120329_095413, Andrei POPESCU wrote: > On Mi, 28 mar 12, 16:58:03, Paul E Condon wrote: > > > > > > You could have also considered uncompressing the tarball somewhere else, > > > like $HOME/tmp or $HOME/src, but it sure is a valid solution, especially > > ^^^^^^^^^ ^^^^^^^^^ > > > > On my computer that is running wheezy neither of these suggestions work, > > because, I think, these are not mount points supporting access to external > > physical disk hardware. > > You must be misunderstanding me, I meant "some directory in your home", > because on most systems /home has enough space.
No. You misunderstand me. There is a new extra requirement on TMPDIR, a restriction on ones choise of its value. A directory entry on a disk file system is not enough. It must be a directory entry that has a line in /etc/fstab that enables its use as a mount point to real separate partition. At least that is the way it is now. If this restriction were removed by some change in the implementation that I know not how to do... then your suggestion would likely work and the old way of using /tmp would also work. > > I tested this suggestion this morning. I don't > > fully understand this, but I have been told that access to the original > > /tmp file requires an entry in /etc/fstab. In UNIX all directories are files ... special files that serve a special system defined function, but files in the sense that they are not inodes, or sectors, or blocks, etc. Linux follows UNIX on this innovation of long ago. > Err... your original /tmp is a directory on / not a file[1] and if you > don't mount anything there your system will happily use the available > space on / (the root partition). > > [1] unless you had a dedicated partition, but AFAIK in such a case you > wouldn't get a tmpfs anyway I don't know why I get a tmpfs. I didn't ask for it. I have supposed it came with a new way of doing file handling in the system software, part of a new implementation that was supposed to be a work-alike replacement of the previous version. I never had a dedicated partion for /tmp and now it is required. That, to me, is a change. I fixed it when I learned that it is now required, and I think it would be nice to go back to the old way because the old way did not require a separate partition. But I repeat myself. Enough. What happens will happen. > > > Think about it. Who is supplying this extra hardware? Any specialized > > software that requires scratch files because the work is too large to > > fit in ram is dead in the water with this change, and changing the > > setting of RAMTMP does not fix the problem, or any of the work-arounds > > that have been suggested so far. I think this is a serious flaw in the > > current wheezy, a release critical flaw perhaps. My particular problem > > is a project in which I regularly need to sort files 2 to 3 GB in size > > on a computer with less than 1 GB of ram and 370 GB of rotating disk. > > > > But I am sure there are other problems needing real, physical scratch > > space running very nicely on computers old enough to have once run > > woody. And now they are to be broken by something in wheezy software? > > Can this happen? Really? > > Why do you think such scratch space should be in /tmp (regardless of > whether /tmp is on tmpfs, a separate partition or just a directory on > /)? > > Kind regards, > Andrei > P.S. I accidentally did some re-wrapping, how long do you set your > lines? The default in mutt, whatever that is. I like defaults. That is the main thing that originally attracted me to Debian. It offered defaults that worked. -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120330204437.gc3...@big.lan.gnu