I’m wondering if there is any danger in removing all of the empty directories from the “custom” subdirectory in the repository, or if something in Deadline will break if that stub directory structure isn’t in place.
Thanks.
I’m wondering if there is any danger in removing all of the empty directories from the “custom” subdirectory in the repository, or if something in Deadline will break if that stub directory structure isn’t in place.
Thanks.
I wouldn’t recommend it. While some stuff would probably work fine still (ie, checking if a specific plugin has a customized version), we do directory listings of some of those folders in specific instances, which could break things in unexpected ways. We should be handling exceptions in most of those instances, but it’s hard to say unequivocally that deleting those folders would do nothing. It’s certainly safer to leave them in
Cheers,
Jon
Hmm, OK, thanks for the info. It would be really nice if those directories didn’t have to exist in a future release…
Hey Nathan,
Can I ask why the need for removal?
Many users have found it critical to split their in-house code from our shipping version and yet, you can easily install over the top a minor upgrade seamlessly. Could you just remove ‘write’ permission if you don’t want users to create files in this sub-directory structure or place the ‘custom’ directory under GIT/SVN control, so you know if it’s been changed?
I’d like to understand the use case if there is a workflow we are missing here?
Cheers,
Mike
It’s not about controlling access to the directory… it’s that I needed to clone a git repository from our repo server into the directory, but couldn’t since it wasn’t empty. I ended up having to move the directory out, clone the code repo, and the replace the missing directories. In general, though, relying on empty directories existing in a directory that’s meant to be user-editable seems like it’s asking for trouble.