Created attachment 4535 [details] Test case Nothing stops rename() being told to rename foo to foo. For example this doesn't produe an error: $ touch foo $ python3 -c "import os; os.rename('foo', 'foo')" However when run under pseudo the rename() wrappers throw away the information for the old name, losing ownership data etc. Attached is a test case to demonstrate this. A simple strcmp in the rename() wrapper is enough to fix this, although that's both horrible and doesn't fix renameat().
Seems mostly harmless but it might be causing some autobuilder failures or other problems.
Only just started looking, but it seems like if the target of a rename exists, info about it is deleted. Then, the info for the renamed file is assigned to the rename target. Of course, in this case, that info is gone.
In the appropriate "guts" files, move the check for old/new identity to before playing with the pseudo database. Works for rename() and should work for renameat() and renameat2().
Created attachment 4716 [details] testcase for rename() and renameat()
merged to master and seems to be passing tests so closing: https://git.openembedded.org/openembedded-core/commit/?id=6b3d109f42385ad1cf1f297a6c06ea7eb6509f26