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 <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
