yeah, there was a stat bug that was fixed. some filesystems modify the
block value before passing it back. drosen fixed sdcardfs to look at this
in "ANDROID: sdcardfs: Get the blocksize from the lower fs":
int f2fs_getattr(struct vfsmount *mnt,
struct dentry *dentry, struct kstat *stat)
{
struct
thanks. replied on the list, s/i/drosen/ :-)
On Fri, Apr 7, 2017 at 6:55 PM, enh wrote:
> yeah, there was a stat bug that was fixed. some filesystems modify the
> block value before passing it back. drosen fixed sdcardfs to look at this
> in "ANDROID: sdcardfs: Get the
Yeah, but that's a big job for the future. I am root and can spin up a new
emulator instance and throw it away afterwards at very little cost (for
x86/x86-64). So it's still useful in the usual "half an eye is better than
no eye" sense.
On Apr 7, 2017 09:47, "Rob Landley"
Wrong train of thought, toybox stat doesn't do any blockcount calculation,
but just gets the value from `st_blocks`.
We are getting bad values from `/storage/emulated/0` which is FUSE mounted
from `/data/media/0` and the blockcount values from `/data/media/0` are
sane.
So this seems to be FUSE
On 04/03/2017 10:35 AM, enh wrote:
>
> Parsing file(1) output isn't a good way to determine file system type
> anyway.
The mount tests (which there need to be s many more of, there's
comments in mount.c about that) are one of the category of "tests really
needing mkroot" because:
A)
On 04/03/2017 10:58 AM, enh wrote:
>
> Also try to only kill processes we created.
> ---
> tests/losetup.test | 6 ++
> tests/renice.test | 4 ++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
I applied the renice part of this, but not the losetup part of it.
Rob
I'm using stat to display filesize and allocated size in my Android app.
I calculate the allocated size by multiplying the block count (%b) with 512
Byte.
I found out in https://github.com/landley/toybox/issues/41 that the
blocksize for the blockcount calculation is hardcoded to 512. So this
On 04/07/2017 11:50 AM, enh wrote:
> Yeah, but that's a big job for the future. I am root and can spin up a
> new emulator instance and throw it away afterwards at very little cost
> (for x86/x86-64). So it's still useful in the usual "half an eye is
> better than no eye" sense.
Oh sure, I'm