Dyn Backup File Location / Options

Hi All,

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 :face_with_raised_eyebrow:

1 Like

I was thinking the DynamoSettings.xml file is where the backup folder location would be specified, but it doesn’t appear to be… :thinking:

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.

1 Like

Thanks for the reply.

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


Specifically this replication.

The number of backups here is not referenced in the .xml settings file previously mentioned.
Any thoughts?


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?

Our IT department is pretty switched on (only a little pun intended…) :yum:

We are running on an optimized Cloud Server (Nasuni) as Revit is our dominant documentation solution.

It assesses files for multiple criteria (duplicates, orphans, file corruption) upon access by any user within our nationwide company network.

I will probably compile some kind of executable that assesses our centralized Dynamo Library and singles out the backups for removal.

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 :sweat_smile: 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.

1 Like

Where are your packages located? Are they on your machine or is Dynamo pointed to a network location?

Mine are on the network and all the folders/packages have been recently downloaded and placed there.

What I find odd, is that the downloads were done from the Package Library Website (https://dynamopackages.com) and the backup folder does not exist in the actual contents of the downloaded zip files .

The backups that exist in the package folders on the network drive are all .dyf files with dates ranging from today to early 2016… :face_with_raised_eyebrow:

I’ll remove all the backups and bookmark this topic to provide an update at the end of the week.

Thanks again for the help @awilliams :+1:

Thought I should let Dynamo tidy up its own mess.


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 :grinning:).

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 :rofl:

1 Like

Why not just make the packages directory read-only? That way you shouldn’t get any backup folders at all.

I recall an issue once where some packages need read/write to work correctly. Perhaps the zero touch based ones.

@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. :thinking: Is this an incorrect assumption?

That may actually be the case. I was under the impression that they also get generated when a script uses custom nodes authored in older Dynamo versions but I might be wrong.

1 Like

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 :pray::heart: 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… :face_with_raised_eyebrow:

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:
cd Drafting\Dynamo\Packages\
del /S *.backup
1 Like

Hence my suggestion to keep the directory read-only. This has worked for us beautifully for the last two years.