I submitted a patch to fix bb.utils.lockfile to at least break the loop and fail when a too long filename is passed with https://lists.openembedded.org/g/bitbake-devel/message/12850
Nevertheless, you have a good point here: Fixing the code that constructs the filename of the lock files would be the better solution. For the sstate files only lockfiles of .siginfo files can overlap, because the filename of the actual sstate file is already 8 characters shorter than 255 characters. I have one though on that: >From what I have seen, the filename of lockfiles is mostly constructed by >appending ".lock" without any further check. Truncating the filename of the >lockfile inside bb.utils.lockfile could be confusing however, since the >function would not use the filename that is was explicitly passed. Hence, I >guess bb.utils.lockfile should fail when a too long filename was passed, and >the function building the lockfile's filename should ensure to keep it >limited; that's bb.fetch2.FetchData.__init__ then if I'm not mistaken. Would >you agree? Or would you say, changing the filename inside bb.utils.lockfile is >ok, as long as the function is working? The drive-by fix I made with using limit instead of 254 when shortening the filename is still correct and necessary, right? Best, Manuel May I suggest two solutions here: a) Let bb.utils.lockfile
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157699): https://lists.openembedded.org/g/openembedded-core/message/157699 Mute This Topic: https://lists.openembedded.org/mt/86725115/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
