[Toybox] st_blocks

[enh]

Thoughts? Should I just pick a number and send a patch?

On Sat, Sep 28, 2019, 09:46 enh <enh at google.com> 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)). 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.
> >
> > 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...
> >
> > 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
> 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?
> >
> > If not, 1 or 2 seem like the least awful. Let me know which you prefer,
> if you don't have a good solution I haven't thought of...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20190930/63d7a112/attachment-0001.htm>