On Wed, 2022-03-02 at 21:55 +0100, Konrad Weihmann wrote: > An interesting behavior struck me once more after a long long time. > > *** 0002:extend_recipe_sysroot(d) > 0003: > File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 584, > function: extend_recipe_sysroot > 0580: if "/bin/" in l or "/sbin/" in l: > 0581: # defer /*bin/* files until last in > case they need libs > 0582: binfiles[l] = (targetdir, dest) > 0583: else: > *** 0584: staging_copyfile(l, targetdir, dest, > postinsts, seendirs) > 0585: > 0586: # Handle deferred binfiles > 0587: for l in binfiles: > 0588: (targetdir, dest) = binfiles[l] > File: '/layer/layer/poky/meta/classes/staging.bbclass', lineno: 158, > function: staging_copyfile > 0154: os.symlink(linkto, dest) > 0155: #bb.warn(c) > 0156: else: > 0157: try: > *** 0158: os.link(c, dest) > 0159: except OSError as err: > 0160: if err.errno == errno.EXDEV: > 0161: bb.utils.copyfile(c, dest) > 0162: else: > Exception: FileExistsError: [Errno 17] File exists: > '/build/tmp/sysroots-components/x86_64/some/path/to/some/deeply/nested/file' > -> > '/build/tmp/work/x86_64-linux/some-recipe/1.0-r0/recipe-sysroot-native/some/path/to/some/deeply/nested/file' > > This happens in rare case when doing a differential build o a recipe > with hundreds or thousands of native dependencies. > > The file mentioned is pretty much random and it's unique (no duplicates > among all the dependencies when it comes to filename+path). > > So far I helped myself with ignoring this error by adding > > except FileExistsError: > pass > > to staging - I wonder if anyone else ever seen this behavior and what's > the best way to deal with it > > What comes to my mind is > > - ignoring it - but then no one can be sure it's the right file > - falling back to the OSError/EXDEV path and copying over the file requested > - a 3rd option > > Any thoughts? > > (Just to be sure, this happens like once in a thousand builds and only > on differential builds)
My initial thought is that is a horrible work around and we need to get to the real issue. The question is where is the duplicate file coming from and why. Also, is this dunfell or master or something else? There were issues that were fixed in these codepaths after dunfell. Is there anything significant about the kinds of files this is being hit with. For example are they generated pyc files? We have see that issue before. Is there anything significant about the path lengths involved? It is hard to tell from the information provided. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#162629): https://lists.openembedded.org/g/openembedded-core/message/162629 Mute This Topic: https://lists.openembedded.org/mt/89511363/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
