[AndyL]

I have MSPro storage set up so Manage my files is selected and so is delete original after copy and I have set my own storage location. Normally I copy PDFs to a download folder and let MSPro move them to the storage location.

Recently I was updating some PDFs, so copied them straight to the storage location. This included a few new ones, just because it was easier. I then created new songs with these new PDFs. This all appeared to work, except when I came back to the new songs I found the PDFs had been deleted.

It looks like MSPro had deleted the file after doing the copy, except no copy was necessary and the file being deleted was the original.

We have talked about this before and I thought we had come up with a solution. If we did, it doesn't work. I seem to think there were problems working out if the original and the "copy" were the same. An obvious thought is to copy the file to a temporary name, delete the original, then rename the copy. This should work for all situations.

Something else that was discussed was the settings. In the old MS, the store options were available as part of the "new song" setup. Whilst I don't think you need all of the options, it might be nice if the "delete original after copy" option were easily available on the file tab of the new song pages.

Regards

Andy

[Zubersoft]

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.

[AndyL]

OK, sounds like you've found a probable cause.

I can repeat this quite easily. I thought maybe something else had gone wrong when I first noticed it, so I tried again and it deletes the file every time.

The problem with your sequence is if #1 fails you end up with no file too. I'm not sure which is more likely, 1 failing or 4. Personally I would have thought 1. Also you are more likely to know if the rename has failed, whereas you can't tell if 1 has failed. I'd change the sequence.

I guess if the copy/delete process works and is safe then the setting change becomes unnecessary.

Regards

Andy

[Zubersoft]

I swapped steps #5 and #4, as I think that's probably best. If step #3 fails, then it exits before the delete happens. It step #3 succeeds, then there is no way that the rename should fail.

Thanks,
Mike

[AndyL]

OK, sounds safe. The only slight thing. In my particular case step 3 will delete the original file, so (the new) step 4, deleting the original, will fail (or ate least not delete anything). So this shouldn't cause things to exit.

Regards

Andy