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
Touch seeded
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
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
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
5 matches
Mail list logo
