Closed chadalon closed 2 months ago
Also something to consider is just general time since file was created. If we just ran the script on a file we should be able to revert it easily (but if there are other songs in the selected directory that are old those should obvi still cause a pause)
Currently I updated the UpdateFiles
to set the new .song file's creation date to be the date it is created by the file finder. Then the restore files checks to see if the last modified date is later than the creation date, and if it is, the prompt is triggered.
My concern now is if you update samples, modify the song with S1, update samples again, then restore, your modifications will get nuked.
One possible solution is to check if there's a corresponding backup file. If there is, check the .song to see if it's been modified since its creation date. If so, set the new file's creation date to the old one's.
Now I just thought of something. I think the date last modified doesn't get changed when these files are created/moved. Could maybe just use that instead of worrying about the creation date at all. Upon restore if the file we're gonna restore has a last modified date different than the backup, we would prompt the user. If this isn't the way it's affected anyway we could set the last modified date (might as well, this way it won't mess up anybody who wants to keep track of that stuff (dates)).
Need to add a stop button on this prompt in case the user wants to get out of it if it keeps popping up. Very much an edge case though. #49
If you restore a file and it was created like 10 weeks ago, maybe force a prompt to the user (bc they might be nuking all their work in the last 10 weeks). If it was created and last modified on the same exact timestamp, it is probs fine. Also this prompt should have a cancel button as well to get out of the restoration process.