On 8/1/16 5:55 PM, Richard Purdie wrote: > On Mon, 2016-08-01 at 15:17 -0500, Seebs wrote: >> On 1 Aug 2016, at 15:01, Richard Purdie wrote: >> >>> No, we're actually expecting it to retain the mode it was given via >>> the >>> hardlink under pseudo. >>> >>> This is what a real world system would do and in this case we could >>> track it via pseudo since pseudo is loaded when the hardlink is >>> created. It would be unreasonable for pseudo to track all hardlinks >>> but >>> tracking ones created under it does seem reasonable? >> >> Hmm. Well, strictly speaking, the link created under pseudo *does* >> get >> tracked. Hmm. But an implicit request to track also the thing linked >> to >> is not a horrible idea. Although you'd still be able to beat it: >> >> $ touch file1 >> $ ln file1 file2 >> $ pseudo >> # ln file2 file3 >> # chmod 777 file3 >> # rm file2 file3 >> # ls -l file1 >> >> The general case of "find everything this link also refers to" is >> clearly out of scope. > > Agreed. > >> That said... Hmm. I think my main feeling is, if we want >> to link to the file, and we want the changes to the linked file to >> survive, we should probably either create that file under pseudo, or >> explicitly claim it with pseudo when we start wanting to do the >> tracking. >> (You can trivially do this to a tree with chown -R root tree). > > The trouble is that for speed, we do create trees of hardlinked files > and play games with those and sstate amongst other things. Its > obviously faster to do this than make physical copies of the files. > Given what I know of the code paths, I suspect that tracking the source > of a hardlink would make life much easier for us. Obviously we can go > and start adding "chown -R" calls everywhere but that seems a little > ugly to me and doesn't do performance any favours. > > Is there any significant downside if we do track the source of > hardlinks?
Would it makes sense to track the xattrs and linked files and such using some type of inode reference (virtual or otherwise)? Since in the case of a hard link, on a normal Linux style filesystem, there will be a single inode that has a reference count higher then 1. Thus you can know the modes, xattrs, etc for that inode.. then the file points to the inode with reference counts. (this might require a rework on internal structures.. but also might solve the problem.) --Mark > Cheers, > > Richard > > > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
