[Toybox] [PATCH] dirtree.c: avoid spurious EINVAL warnings.

[Rob Landley]

On 12/16/19 1:20 PM, enh wrote:
> On Sat, Dec 14, 2019 at 3:37 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 12/13/19 6:36 PM, enh via Toybox wrote:
>>> An Android engineer complained that they were seeing this when not
>>> running as root:
>>>
>>>   $ adb shell ls
>>>   ls: ./postinstall: Invalid argument
>>>   ls: ./init: Permission denied
>>>   ls: ./data_mirror: Invalid argument
>>>   ls: ./init.environ.rc: Invalid argument
>>>   ls: ./metadata: Invalid argument
>>>   acct
>>>   adb_keys
>>>   apex
>>
>> Are you sure that's current? init isn't listed to stdout: the current code is
>> saying "permission denied" but also listing them.
> 
> yes, this was ToT. note that by default adb shell doesn't allocate a
> pty, so you're seeing all the stderr before you see any of the stdout.
> 
> `adb shell -t` gets you a pty *if* you have a tty yourself. `adb shell
> -tt` forces a pty. this was copied from ssh, but in retrospect i think
> we should have defaulted to the `-t` behavior. i assume it would be
> too disruptive to change again now.

The fundamental assumption of adb is that you're accessing the Android device
remotely from a "real" computer, and the model I'm working towards is making the
Android device _into_ a "real" computer.

>> Not sure what the right behavior is here. (It's a UI question really.)
> 
> i think we're already there, aren't we? the only reason we were seeing
> any errors above was because of this bug. the EACCES on init was
> because that *is* a symlink so we didn't get EINVAL like the others,
> but with the fix, everything looks right to me (if you assume that the
> coreutils "? for stuff we don't know" is the desired behavior, which i
> think is probably as close to ideal as you'll get):

I applied your patch back on friday, hopefully it's all good now.

Rob