[Toybox] [PATCH] roadmap update: Android switched to toybox ls today.

[Rob Landley]

On 05/15/2015 08:17 PM, enh wrote:
> roadmap update: Android switched to toybox ls today.

Sorry, been sucked away into $DAYJOB recently, flying back to Japan tomorrow
and trying to get stuff done before then. I am _waaaaay_ behind on the
list, and need to basically reread this whole month's web archive and
deal with stuff in order. (I've downloaded smack-10 to look at on the plane.)

The dirtree_parentfd() stuff not working is because the filehandle gets
closed by the time dirtree_recurse() returns (see line 330 where we dup()
one to avoid that), which means we have to read the xattr string and store
it during the traversal. The actual callback that collects this data is
filter(), so that's the logical place to snapshot it, but ->extra is already
used to signal this argument came from the command line (I don't remember
why). I can malloc a struct but don't want to if I can avoid it.

Looking at ls_main() and the strange way we have an empty top of tree
node crated with (0,0), I vaguely remember this was to get some aspect of
the ls -R behavior right (when to print or not print directory labels?)
and this is when, before I start fiddling with it, I REALLY want there to
be a tests/ls.test with regression tests for all these weird corner cases
I had to get right at the time and am worried about breaking now just because
I don't remember what they all _are_.

So I was briefly happy to see there's an ls.test, but it's an external
contribution that doesn't actually test any of the things I'm worried about
breaking here. (This is why I need a "pending" directory for the test suite.
And really need to spend lots of time making what I consider to be proper
test suite entries for each command.)

So my next todo item there is working out why I implemented it that way,
and if I can easily test that top-of-tree thing at runtime and thus
repurpose dirtree->extra without mallocing an extra struct for it.
(The painful bit would be mallocing _just_ the flag in the non-lsm-label
case.) I think I can, but need to work through to be sure.

But meanwhile, I'm back looking at the smack-10 branch starting from
the new lib files, which is another message...

Rob

 1431797197.0