Not sure how the truncate tool works internally, but it does the same
with the -s parameter.
$ truncate -s 48T size-test
truncate: failed to truncate 'size-test' at 52776558133248 bytes: File too large
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subs
Well ... the tool could print all possible reasons of the failure to
avoid confusion. Writing one byte at the last position seems to me a
good solution. If that's acceptable, it would really improve the user
experience. Thank you.
--
You received this bug notification because you are a member of
Today, we don't create the sparse file "with the required size" when it
is first opened. We could try seeking to maximum size of the device
and writing a single byte, and seeing whether or not that fails, and if
it fails, *assume* that this was caused by the target file system not
supporting such
Oh, sorry, I thought the limit cannot be reached that easy in case of
sparse files full of unalocated blocks. Apparently the limit includes
the unallocated space.
I retested that again and the sparse file really gets truncated to 16TB
and I believe that's exactly the moment when the tool should re
If the file system has a limit on the size of the file (for example,
ext4 has a maximum file size of 16TB), then when you do a relative seek
via llseek(fd, offset, SEEK_CURR), the system call will return EINVAL.
This is what is causing the error.
If you want to create a raw image of a very large f
