Grep should help with that. Try this (the original command isn’t useful because it only traces the initial command):
strace -o …/ouptut/read -ff ./Fritzing
(the -ff in the command traces forks) then there will be a lot of files of the form read.123 where the .123 is the pid of the forked task. You need to create a directory output beside the Fritzing directory (to keep the strace files somewhere easy to delete without deleting Fritzing!) for the …/output above to work. Then
grep open …/output/read* | grep ‘= -’
should get you only the file open calls which fail (negative return codes usually indicate failure.) One of those should be the file that is causing the failure, and the file name should be in the command line so you can look at its permissions. I suspect you will find something that is owned by root from the initial install that isn’t being deleted by anything we have done so far.
edit: Come to think of it, you probably need to change open to write above. If you have read permission (which is likely) the open will work but the write will fail, so we need to be looking at the write system calls not open.
edit2:
Another late thought: if you have not already done so, do an ls -laR on the Fritzing install directory and the two user directories to make sure all the root owned files and directories were actually deleted. If any of the files or directories in any of the 3 directories are owned by root rather than your user ID this type of error will occur. That seems more likely than a temp file somewhere to me.
Peter
)