Re: What to do if $TMPDIR runs full?

[Ole Tange]

On Sun, Dec 1, 2013 at 7:25 AM, George Marselis <george@marsel.is> 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