Hi Peter, as I promised, I started testing the bug in the lab this morning. I was wrong about NFS: it's actually sshfs, and it may be important since while trying to isolate the bug, I've found that gsch2pcb failed to execute an mv command, probably due to sshfs. I will go on and test mv by hand.
The following tarball contains all related files: http://inno.bme.hu/tmp/xgsch2pcb_bug.tar.gz bug1/Readme.txt describes how to reproduce the problem and contains all files and the full output in LOG (ran on sshfs); bug2 shows the same on a local dir, where everything works fine. bug4 is a copy of bug2 with path changed; if you open the project and just click on update layout, it already should show the difference: on sshfs there will be 5 components, on local fs there will be 3. I managed to reproduce this with a few weeks old pcb+xgsch2pcb and with recent ones checked out this morning. In both cases gschem version was 200706026. I am not sure why sshfs fails to move the file, but i think gsch2pcb or xgsch2pcb should handle this sort of problem, at least by warning the user about the failed file operation and pointing out where the backup files can be found (the exact file names). Or even, maybe some sort of "undo" function would be nice that reverts to the previous consistent PCB; or even a list of backups so the user can open and evaluate each and select one to use instead of the current one messed up by the failed update. While playing around, I've found another interesting corner case: my students are working in 2 person teams. I wanted them to easily find their project on the remote file system so each student has an own unique directory under his name. To keep teams together, I made one real dir per team and the other dir is a symlink. It should not happen, but if both members of a team starts to edit his layout, there will be two xgsch2pcb instances running on the very same files from two different computers. I haven't tested it, but I think this could cause problems. A simple workaround would be some sort of locking; xgsch2pcb could create a lock file near the project file (with PID or hostname:PID) and the second instance should not open the file until the first instance quits and removes the log. Best regards, Igor2 _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
