On Tue, Mar 11, 2014 at 06:53:36AM -0500, Rob Landley wrote: > Trying to tie off the loose ends for a long-overdue release, and > Isaac's cpio -d patch is half-finished in my tree. > > The problem with the original patch is that "mkdir -pm 500 > one/two/three" should work creating a read only "three" under a > read/write "one/two". If "one" is read only it fails to create > "two". Thus the original mkpath logic was that the supplied mode > only applied to the _last_ directory component, and the others just > used the umask. But the version of the function moved to lib isn't > doing that, which breaks mkpath.
Ah. Thanks for the explanation. <snip> > By the way, if you notice those games with 0777&~toys.umask, that's > because mkdir has TOYFLAG_UMASK in its NEWTOY() flags, which tells > main() to set the umask to 0 (and save the old umask in toys.umask). > That way when we create things, we get the permission we actually > request rather than a filtered subset, allowing things like mkdir -m > to work properly. I note that toys/pending/cpio.c is _not_ doing > that, nor is it calling umask(0) itself, meaning it's allowing umask > to filter the permissions of everything it creates rather than > producing output with the actual modes recorded in the archive. Is > this intentional? I wasn't sure what to do, so I tested GNU cpio, and that's what it _seemed_ to be doing. Not that it's necessarily the right thing to do. I guess if someone sets umask to 0477, it will break. But then, a _lot_ of things would break then... Thanks, Isaac Dunham _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
