Hi,
It seems in my deadline repository directory I get a load of these files building up.
Should this be happening? What are they exactly? Can i delete them?
Thanks,
Richard
This files are used by the Deadline applications to get the date/time of the repository machine. They are supposed to be cleaned up automatically, and there is no harm in deleting them manually.
In Deadline 6, we won’t be using this method anymore.
Cheers,
- Ryan
Ok Thanks Ryan. It appears they are not being automatically deleted. But good to know I can just delete them manually.
Thanks,
Richard
Hi,
Our Deadline Version: 6.2.0.32 R (2563d5bc8) Repo still has 50,000+ of these files. Is there a certain condition or configuration that would still cause them to be generated?
Thank you!
It’s an issue with fileservers we never really did track down.
The reason they’re not being deleted is likely due to the lock files in ‘settings’ not being released correctly. We did away with those lock files in Deadline 7.0 and put the farm-wide lock tokens in the database where it’s free from this problem. For now, if you can’t delete the lock files, create a new folder called ‘settings2’ in the root of the Repo, copy over your ‘dbConnect.xml’ and friends, then swap the original ‘settings’ folder for the ‘settings2’ folder. It’s a silly problem.
The good news is it’s finally fixed, but it does require the upgrade.
Hi again,
Just wanted to give you the heads up that this behaviour is persisting for us. We are finally rolling out V7.2.0.18 and we see the same thing; lots of files being created.
My suspicion is that is is permission related as we have the repo folder located on a ZFS folder with special permissions set.
Anyway, just trying to be thorough to report back that our environment still causes this to happen and if you need any more information from me, please let me know.
I will probably proceed and either use your suggested “trick” above or change the permissions.
Thanks again.
Actually, it looks like my brain was set on the lock file problem, not the buildup of “connectReadWriteTest” files (it’s painfully obvious given the title of the the thread I was wrong there).
Permissions definitely will cause issues if the ZFS ACLs are set a certain way. I’ll push again that we should only do the R/W test on app startup.