- removed comment
simfactory sync can lead to inconsistent builds
Issue #737
closed
simfactory's sync command uses rsync with the --archive (-a) option. This option set the modification date of files on the target machine to that on the source machine. This can lead to inconsistent builds in the following situation:
[1] local: edit source_file.c [2] local: simfactory sync [3] local: edit source_file.c [4] remote: simfactory build [5] local: simfactory sync [6] remote: simfactory build
[6] will not rebuild source_file.o since [5] set the modification time to that of [3] which which is older than [4] hence make will not consider source_file.o to be out-of-date.
A simple fix is to add --no-times to the rsync options. Unfortunately this disables rsync's file modification time optimization and requires it to compute checksums on all files which can be very slow on slow filesystems.
Keyword:
Comments (6)
-
-
- removed comment
You could also force build to do a sync first. I think this should be the default. One of the aims of simfactory is to stop the user making mistakes, and forgetting to sync before a build is a very easy mistake to make. Another is to forget to sync the parameter files before submitting. This should also be automated. If someone knows they don't need to sync, they could use something like --no-sync to override.
-
- removed comment
I like this idea.
-
- removed comment
If we go so far as to capture and parse the rsync output, we could touch whatever rsync copied after it is done. This updates the timestamps on the remote side, and does so only for whatever rsync thought is different. The catch would be that rsync would, for future copies, always copy these files again because the timestamp would always differ. This could be turned off with the --update option (which does not transfer files which are newer on the receivers side than on the senders side). However, this might also not be what you want in case you do want to overwrite remote modifications.
A forced sync does not help if the build is initiated on the remote machine (I usually work directly on the remote side and do not use the --remote simfactory option).
-
reporter
- changed status to resolved
- removed comment
Fixed in rev 1965 of simfactory (which uses --checksum and --no-times).
-
reporter
- edited description
- changed status to closed
- Log in to comment
Yes, this is a problem.
I don't see a good solution, except using --no-times which is really too slow to be useful.
We could capture rsync's output, and remove any object files corresponding to the copied source files. This would include some guesswork for the make rules. Alternatively, we could create "this-file-has-been-modified" markers from rsync's output, and look for such markers (and delete them) in the Cactus makefiles.