I have been advised by our IT department that files recently accessed by some users are duplicate files.
Specifically these have been identified as the .dyn automatic backups in each package folder in our package library on our network drive.
Is there any way within Dynamo to specify where these backups are placed? (e.g. one folder/a central location that can be cleared)
I don’t really want to disable the backup function (if that is even possible) as I feel it an essential for protecting our workflows. The routine clearance of any backups would be likely handled by an external script/application to avoid IT tapping me on the shoulder more often than they already do
I was thinking the DynamoSettings.xml file is where the backup folder location would be specified, but it doesn’t appear to be…
I would think changing the value for <BackupFilesCount>1</BackupFilesCount> to <BackupFilesCount>0</BackupFilesCount> in the DynamoSettings.xml file would disable the backup function, though not ideal.
I have just tested that and yes, changing the value will disable the backup in the following folder: C:\Users\XXXX\AppData\Roaming\Dynamo\Dynamo Revit\backup
But upon restarting Dynamo, this value is reset to 1 for some reason. I don’t want to disable it for good though.
Upon further investigation, IT have told me .dyn when it is in fact .dyf
I think if you just replace the <BackupFilesCount>1</BackupFilesCount> line with <BackupFilesCount /> it would prevent it from having a value at all and prevent it from resetting upon restart, but I can’t be certain without trying. In any case you don’t want to disable it for good, and it seems that the backup files in question are likely unrelated to that .xml file.
I’m at a bit of a loss on a solution or where these backup settings may reside but I’m speculating that it may be written into the packages themselves. It seems that some packages allow for many more backups than others (ex. it doesn’t seem as if there are any more than 4 backups per .dyfs I’ve opened in Spring Nodes, but a rather large unknown maximum for Clockwork and Rhythm; this could be due to how many times I’ve opened them and/or left them open, not sure).
I’m curious now as to whether or not any of my nodes are loading from the package backups folders as well. How did it become apparent to your IT department that this was happening with other users?
Hmm so I noticed that mostly all of the backups in the package folders’ created/modified dates are as early as 2015 and most from before I even knew what Dynamo was I’m thinking they are carried over when the package authors upload their package files. I ran a Dynamo graph that searched and deleted all files ending with .backup within the packages directory, then opened up a few nodes to see if any backups were generated within those folders and they did not - they backup to the typical backup folder. I think deleting them once will suffice (save for when there is an update). I’ll be keeping an eye out for if any of them happen to appear again, though.
Mine are only on my machine; I’m the only Dynamo user and we haven’t upgraded our projects over to 2018 yet and are still on 2016 (which has been kind of a plus to allow me to slowly be developing scripts for the Dynamo player that are ready to go for my coworkers to use when we make the switch ).
I wish I had looked over more thoroughly the range of dates on mine - once I noticed some were as old as 2015 and had the realization that it was impossible to be due to my use of the files, I went ahead and did the same exact workflow you did above to see if any were created again in the same folders when I opened nodes afterwards.
I’m still thinking that if they are in fact being created within the dyf backup folders within packages upon user end editing (recent dates), it is likely something written into the package script since it doesn’t seem apparent that it is controlled by the DynamoSettings.xml file. Maybe a package author might chime in and confirm, deny or elaborate on this.
In any case, we both semi-solved the problem with the graph above, so lets go ahead and make that a custom node and use it to delete its own backup files later
@Andreas_Dieckmann It appeared to me that backup folders within packages weren’t created from me opening any of the custom nodes and since I cleared them out and have opened/closed custom nodes the only backups that generate are within the typical backup folder location (\Dynamo Revit\backup). I was thinking that they were downloaded with the packages. Is this an incorrect assumption?
Perhaps you could check the files you upload when uploading your package to see if its including backups as well to verify this? (which by the way, thank you so much for your work I use Clockwork almost more than any OOTB nodes!)
Some uploaded packages do have these backup files within them but the majority dont.
This may have caused the initial duplicate warning.
As for your thought @Andreas_Dieckmann this appears to be correct.
I have multiple users accessing scripts that do use nodes authored in older versions (1.2 being used in 1.3) which exponentially adds to the duplicate warning problem. Each time a user runs my script (possibly 5 times in an hour) a backup is made for them. So 5 users over the course of an hour have created 25 back ups!
My script that clears these backups works fine, but i have the feeling my IT department will need to pur a task in place to do this more regularly…
EDIT: Here is the code content of a simple .bat file that can be run on PC startup to perform the same task. (Obviously adjust the directory path to point to your packages location)
cd /D P:
del /S *.backup