Andy,
I'll have to test this out. Nothing should have been done in the example you gave because I also test to see if the input file is identical to the output file. This uses hashes for the comparison, so it doesn't rely on paths. I don't know why the file would have been deleted as that check should have resulted in the copy doing nothing. Having said that, this is my current process for copy files:
1) Check if files are identical, if so, bail out
2) Copy the source file to the destination path but with a timestamp appended at the end
3) Delete any file that currently exists as the destination path
4) Remove the timestamp from the copied file so it matches the destination path we want
5) Delete the original file if set up to do so
6) Set the last modified time
#5 could still be a problem though if the source matches the destination and the #1 check fails. I don't want to move step #5 before step #4 because if the rename fails for some reason, the user is left with no original file anymore. I'll let you know what I find.
As for moving the "delete original after copy" setting to the song editor, I could put it on the song editor settings dialog , but is that something people are going to be switching on and off frequently?
Regards,
Mike
EDIT:
One of the parameters to my copy file function is whether to perform step #1. Turns out the song editor is passing false so that it isn't doing the #1 check. I'm going to set that to true so that the logic works as expected. This should take care of the issue.
I'll have to test this out. Nothing should have been done in the example you gave because I also test to see if the input file is identical to the output file. This uses hashes for the comparison, so it doesn't rely on paths. I don't know why the file would have been deleted as that check should have resulted in the copy doing nothing. Having said that, this is my current process for copy files:
1) Check if files are identical, if so, bail out
2) Copy the source file to the destination path but with a timestamp appended at the end
3) Delete any file that currently exists as the destination path
4) Remove the timestamp from the copied file so it matches the destination path we want
5) Delete the original file if set up to do so
6) Set the last modified time
#5 could still be a problem though if the source matches the destination and the #1 check fails. I don't want to move step #5 before step #4 because if the rename fails for some reason, the user is left with no original file anymore. I'll let you know what I find.
As for moving the "delete original after copy" setting to the song editor, I could put it on the song editor settings dialog , but is that something people are going to be switching on and off frequently?
Regards,
Mike
EDIT:
One of the parameters to my copy file function is whether to perform step #1. Turns out the song editor is passing false so that it isn't doing the #1 check. I'm going to set that to true so that the logic works as expected. This should take care of the issue.