On 8/2/16 2:19 PM, Seebs wrote: > On 2 Aug 2016, at 10:12, Mark Hatle wrote: > >> So the problem is -- pseudo is modifying the 'original' file perms, >> which on a >> new instance of the pseudo database then gets inherited. So we get >> unpredictable results if this is the first time through -- or not the >> first time >> through. > > Yeah. And the problem here is in part that we're calling chmod on a file > linked to a file external to pseudo, but we're also checking that file's > mode to find out what permissions we want it to have. Which is probably > an error. > > So, it does look like we need the tracking, but also if we stopped > doing: > > stat file1 # obtain mode > ln file1 file2 > chmod <mode> file2 > > we'd save significant time AND avoid the problem. > > -s >
The alternative to the 'ln' is a 'cp' operation. This is how it used to work until optimizations were added a few releases ago. It was observed that this saves a large amount of space -- but it had the unintended consequence of suddenly files are now changes as the do_install/do_package processing manipulates files and modes change... I almost wonder if in pseudo we should avoid changing any modes internal to the file -- until something tries to write to the file. (Can we even capture that and try to fix it? If not, what we're doing is likely the only answer.) --Mark -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
