As noted in the help line today, there is an issue with how Matlab's copyfile does copying. The situation at hand is this:
Preprocessing was previously run by user A, so there already exist preprocessed files
User B now wants to re-run preprocessing, but it fails
This is because copyfile implicitly uses cp -p to preserve some attributes, including timestamp, of the file. Unfortunately, Linux does not allow you to preserve timestamps when a different user owns the destination file. The copy itself actually succeeds, but it still returns an error about not being able to preserve timestamps. This crashes the preprocessing stream.
Right now it seems like simple workarounds would be either:
1) use a system call to cp instead of using copyfile so that the preserve option isn't used.
2) delete destination files first immediately before the copy. This should be fine to do since they would obviously be overwritten anyway as a desired outcome of re-running preprocessing.
As noted in the help line today, there is an issue with how Matlab's copyfile does copying. The situation at hand is this:
Preprocessing was previously run by user A, so there already exist preprocessed files User B now wants to re-run preprocessing, but it fails
This is because copyfile implicitly uses cp -p to preserve some attributes, including timestamp, of the file. Unfortunately, Linux does not allow you to preserve timestamps when a different user owns the destination file. The copy itself actually succeeds, but it still returns an error about not being able to preserve timestamps. This crashes the preprocessing stream.
Right now it seems like simple workarounds would be either: 1) use a system call to cp instead of using copyfile so that the preserve option isn't used. 2) delete destination files first immediately before the copy. This should be fine to do since they would obviously be overwritten anyway as a desired outcome of re-running preprocessing.