On Sun, Dec 1, 2013 at 7:25 AM, George Marselis <[email protected]> wrote:
>> Maybe it would be possible to append a byte to the tmp files before >> printing them. If ftell stays the same then the append did not work >> and a warning should be written. If it worked, seek back 1 byte and >> truncate. This, however, might slow down printing of a job, and seems >> like a lot of checking to do for each and every job for the off chance >> that $TMPDIR is full. >> >> Do you have ideas for this? > > That sounds good, actually. What happens if $TMPDIR gets full in more than 1 > byte, though? The test will be done after you job completes (i.e. just before printing), so the test will only be done when the file in $TMPDIR is at its biggest. But it might be an expensive test, so I am wondering how many milliseconds will you accept per job to get this test. > It has been about nine months ever since I read the manual and I may be > lagging a bit behind, but is there no switch to say "my file payload for > this job is Nsize?" Or, off the top of my head, is there a way to > automagically figure out the space needed in $TMPDIR? I am not sure I understand this at all. If your input is part of a name of a compressed file and the output is the uncompressed, I do not see a way for GNU Parallel to figure out how much space the uncompressed will take. /Ole
