[Toybox] st_blocks

[Rob Landley]

On 9/28/19 11:46 AM, enh via Toybox wrote:
> the only other idea i've had since: use perl or python to implement #4
> inline. but there's no perl or python on Android devices, and there's
> no way that i know of to SEEK_HOLE/SEEK_DATA in awk. so that seems
> like a non-starter.
> 
> On Thu, Sep 26, 2019 at 5:58 PM enh <enh at google.com> wrote:
>>
>> I shot myself in the foot with my tar test that checks both st_size and st_blocks (via stat(1)).

I was thinking that might work in a mkroot qemu instance, but you have to
control for filesystem.

>> You may remember that I had to add a "don't run these tests on a system with
>> SELinux xattrs" hack to the du tests. Basically, any test of st_blocks will be
>> broken because of SELinux.

Many things are. :)

>> Unlike the du tests, I don't want to disable this tar sparse test unless I have
>> to. But I don't have any non-terrible options.
>>
>> 1. Disable the test for SELinux.
>>
>> 2. Use shell arithmetic to allow some fudge.
>>
>> 3. Use setxattr to try to ensure that we're always using extra space, but then
>> we need to work around failures on file systems without xattrs, and how much is enough, and...

Run the test in a tmpfs mount with xattr support disabled? (I know you can do
that at compile time, can you do it at runtime?)

Or a loopback mounted ext2 that doesn't have xattr support, but again... I know
how to remove it from the driver, I don't know how to prevent it at mount time.
(I don't use selinux much.)

Does vfat support xatrrs? If not, a vfat mount might also provide consistent
results.

But again, providing a mount point means having root to set stuff up. Hence
mkroot...

>> 4. Invent a new tool that actually dumps a map of where the holes are in a
>> file. Unfortunately I'm not aware of any existing tool we could use, so

We do have such a tool, it's called tar.

>> then the test relies on toybox already being installed.
>>
>> 5. Use find -printf %S but because that's just using st_blocks behind the
>> scenes, we'd need a fudge factor only now it would be a float instead of an
>> int, which doesn't seem like an improvement.
>>
>> I haven't been able to come up with anything else, and I don't like any of
>> those options, so ... anyone have a better idea?

Create a reference tarball and see if extract-then-archive can recreate the
reference tarball. (Or the first 2048 bytes of it, anyway.)

Rob