the mount command behaves incorrectly about toybox HOT 4 CLOSED

Blah. Sorry about the delay. (The underfunded startup I work at can't afford to replace people it lost over the past year, so the rest of us gained more plates to spin. Very distracting. Yes, I am catching up on this at 4am.) The simple fix is: - remount = (void *)(long)comma_scan(opts, "remount", 1); + remount = (void *)(long)comma_scan(opts, "remount", 0); The problem is if comma_scan removes "remount" from the option string during early parsing (setting the "remount" flag that changes the behavior to do /proc/mounts lookup to find existing flags to delta against), then we never set the remount flag when collecting the set of flags to apply as a delta, meaning it tries to do a _new_ mount over the existing mount, which either gives you -EBUSY or stacks a new mount on top of the old mount (for tmpfs). The deeper question is "why the heck does rw,remount work then"? And the answer is that comma_scan() is failing to remove entries that match at the end of the list. (Ok, fixed. And that _failure_ is why it passed my initial testing way back when. Sigh...) Hmmm... if /proc/filesystems says that a filesystem type is nodev, I don't _have_ to require two arguments to mount it. I.E. there's no reason: mount -t tmpfs sub Can't work? Try the fstab lookup first, but if it's not there just use basename of sub as the device? Hmmm... that works for tmpfs, ramfs, and devtmpfs, and ntfs claims to need a device, but cifs and fuse are nodev and I'm pretty sure they care. (Use the "device" field as other info). Meanwhile the insane v9fs expects the address to live in the options as special arguments in the csv, because IBM. Sigh... (I need to write nfsmount, cifsmount, and v9fsmount commands. For two of those I could even do a reasonable server. It's on the todo list. But not at this time of morning. :) Rob