Re^2: 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

Comment on Re^2: system and &>/dev/null Select or Download Code

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]
Re^4: system and &>/dev/null by repellent (Priest) on Oct 10, 2008 at 18:02 UTC
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]
Re^5: system and &>/dev/null by Fletch (Bishop) on Oct 10, 2008 at 18:34 UTC
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]
Re^6: system and &>/dev/null by repellent (Priest) on Oct 10, 2008 at 21:28 UTC
Re^5: system and &>/dev/null by mscharrer (Hermit) on Oct 11, 2008 at 09:30 UTC
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]


Perl-Sensitive Sunglasses
	PerlMonks