[Toybox] [PATCH] lsattr/chattr: add missing flags.

[enh]

On Tue, Jan 21, 2020 at 8:49 PM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 1/21/20 3:15 PM, enh wrote:
> > On Mon, Jan 20, 2020 at 9:23 AM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 1/19/20 6:58 PM, enh via Toybox wrote:
> >>> Also update help to include flags that were already added. Remove
> >>> useless duplicative comments. Swich to FLAG macros.
> >>
> >> Applied, but I have a TODO item to see if I should migrate all this to FS_XFLAG
> >> out of linux/fs.h, ala FS_IOC_FSGETXATTR and friends.
> >>
> >> (My understanding is the current stuff is ext2/3/4-specific, and the other
> >> things apply to more filesystems? I think? It's still a todo for a reason. Green
> >> elf needs tests cases, badly.)
> >
> > a grep of the kernel gets more matches for FS_IOC_SETFLAGS than for
> > for FS_IOC_FSSETXATTR, and the former is available all the way back to
> > 2.6 whereas the latter is new in 4.5. so i think the "applicable to
> > more filesystems" thing is still mostly theoretical and the 7 year
> > rule means we need FS_IOC_SETFLAGS for the foreseeable future anyway?
> >
> > i actually assumed your TODO was about the ad hoc argument parsing!
> >
> > i do need FS_IOC_FSSETXATTR though to add `-p projid`. i'll send you
> > the patch for that when someone with a suitable fs tells me it
> > actually works. (i've asked them if there's anything we can do about
> > regression testing chattr too, though i'm assuming this needs us to
> > mount a sample fs we're prepared to modify.)
>
> A nice person emailed me an xattr test fs and I made a todo item to add xattr
> support to tar. It's not hard, just haven't done it yet: it _seems_ to be just
> caring about the contents of the 'x' records looking for, but I can't get binary
> equivalence unless I figure out why "sub3" is becoming "./PaxHeaders.15625/sub3"
> in the x record it creates? It's not an inode number...
>
> Oh: https://www.gnu.org/software/tar/manual/html_chapter/tar_8.html
>
> It's the process ID of the tar process. So they GRATUITOUSLY prevent binary
> reproducibility whenever xattrs are involved, EVEN FROM TWO CONSECUTIVE RUNS OF
> THE SAME TOO ON THE SAME DATA YOU....
>
> Ahem. Right. Moving on. (Add another --stop-doing-that in the test command line.)
>
> In theory tmpfs mounts support xattrs so I can extract a tarball into a tmpfs to
> get reproducible behavior. Still requires root to test, but that should be
> reproducible.
>
> In practice I tried to use /dev/shm on devuan and it gave me "inappropriate
> ioctl for device while reading flags" so as far as I can tell they haven't even
> compiled xattr support into tmpfs in the distro kernel...

(speaking of which, i finally got sick of strerror() returning "Not a
typewriter" for ENOTTY and changed it to "Inappropriate ioctl for
device" today... god knows what the younger generations must think of
errors ending "Not a typewriter"!)

> Rob