in reply to Re: system and &>/dev/null
in thread system and &>/dev/null

Doesn't seem to create a sparse file:

[tmp]$ cat broomduster.pl
open my $fh, '>', 'zeros'  or die "error opening fh: ($!)";
binmode $fh;
print $fh pack "x".(1024*1024*10);

[tmp]$ rm zeros; perl broomduster.pl; ls -lh zeros; du -h zeros
-rw-rw-r-- 1 duelafn 10M 2008-10-09 22:17 zeros
11M     zeros

[download]

However, the following works:

[tmp]$ cat duelafn.pl
open my $fh, '>', 'zeros'  or die "error opening fh: ($!)";
seek $fh, 1024*1024*10 - 1, 0;
print $fh "\0";

[tmp]$ rm zeros; perl duelafn.pl; ls -lh zeros; du -h zeros
-rw-rw-r-- 1 duelafn 10M 2008-10-09 22:17 zeros
12K     zeros

[download]

Good Day,
    Dean

Replies are listed 'Best First'.
Re^3: system and &>/dev/null
by mscharrer (Hermit) on Oct 10, 2008 at 07:14 UTC
    This would not create a 100% sparse file because the last block would be all zero (even you print only one zero). Fletch was right in his above post, the combination of seek and truncate must be used.

    Here my first attempt from yesterday evening to create a halfway secure sub function which doesn't mess-up existing files: 

    sub create_sparse {
    my ($file, $size) = @_;
    return if -e $file && ! -f _;
    return -2 if -e _ && -s _ >= $size;

    open my $fh, '+>', $file or return;
    eval {
        seek $fh, $size, 0 or die;
        truncate $fh, $size or die;
    } or do {
        close $fh;
        return;
    };
    close $fh or return;
    return -1;
}

    [download]
[reply]
[d/l]
      Just curious:
      • Why the need for seek when you're just going to close $fh after truncate?
      • Please expain the eval - close $fh - return logic you're using.
[reply]
[d/l]
[select]

        That's the idiom I've always seen used (seek then truncate), which is why I recommended it back in my post.

        Consulting APUE (well, technically the 1st edition of the same tome; pp 91-92), the discussion there indicates that while SVR4's truncate(2) could be used to extend a file (creating a hole) the 4.3+BSD version wouldn't extend the size of the file. So while seeking then calling truncate is possibly more effort than strictly necessary, it's probably more likely to work regardless of the underlying OS' truncate(2) semantics.

        The cake is a lie.
        The cake is a lie.
        The cake is a lie.

[reply]
        As Fletch already said:
        the seek before the truncate is to improve portability. The perldoc page of truncate says:
        The behavior is undefined if LENGTH is greater than the length of the file.
        so IMHO seek is used to extend the file length first. It works without seek under Linux but might not be under other OS. BTW, seek alone without truncate results in an empty (0-byte) file.

        For the usage of eval and close return:
        This is basic error handling, when either seek or truncate fails I close the filehandle and return, with returns undef(=false) so that the caller know it didn't work. Otherwise I return an non-zero value to show success.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom