Unregistering Folders in Tank vs Moving file system locations to trash

Just hoping for quick clarification on the difference between unregistering a folder using the tank command vs moving it to the trash through the website. Are there any differences that I need to be aware of as I find various cases where unregistering doesn’t work and want to be sure they do the same thing fundamentally.
Thank you

3 Likes

Hey @dreidrage from what I understand unregistering will do a few things. Firstly it will remove the entry from your local path cache, second it will create an Event Log Entry that announces this change which other users will pick up when synching, and third it will retire the entity.

Simply retiring in SG via UI or the API will cause issues with the path cache.

Unregistering due to database issues or entity/path registration conflicts is usually resolved by unregistering multiple paths/entities not just a single one. You may need to look up the tree in your schema to see if any other entities would also register a folders in this tree.

6 Likes

@Halil has nailed it!

Deleting the FilesystemLocation entries manually rather than using the tank unregister_folders or the equivalent sgtk API commands, will cause issues due to the sync events not being created.

If you do ever trash a FilesystemLocation entity manually then you will likely need to run tank synchronize_folders --full per machine, which will essentially wipe out the local cache on the machine and then perform a full resync to match the FilesystemLocation entities in Shotgun.

You should normally be able to unregister folders by id, for example
tank Asset 1234 unregister_folders and this, as Halil mentioned, will unregister not just the Asset folder but also all the registered folders hierarchically underneath it.

If you rename the Asset you should still be able to unregister by id.

If you trash the Asset (even if you recreate one with the same name) you will need to unregister the asset by path instead: tank unregister_folders /projects/my_project/assets/my_asset. Again this will unregister not just that folder but all folders underneath it.

tank unregister_folders --all should remove all FilesystemLocation entities even if the associated entity was trashed.

One thing to watch out for is if you have a shotgun_list_field folder in your schema, and you register folders for example on your asset, with the type prop but then update the asset’s type to say env and create the folders again, it won’t stop you or warn you, but you will now end up with two sets of folders registered for that asset. The same appears to happen if you are using nested folder structures inside your yml files as well.

4 Likes

Thank you! That was a perfect clarification and explanation so I should be able to fix issues and use best practices

4 Likes

Hi folks,

How can I do the same in a distributed configuration environment?

Thanks in advance,
Osama

Hi @Osama.Ali I think this is what you are looking for?

That is the equivalent API command, that you would need to use.

1 Like

Thank you @philip.scadding

I’ve already tried this but no luck, I had to make sure I am trying the right command, so thanks for the reply.

Currently I am going to stay in contact with the support trying to troubleshoot my issue.

Thanks for your help!

Cheers,

Hi @Osama.Ali ,

That should be the right command, we all defer to Philips knowledge here as he is the expert.

Cheers,
David

1 Like

@DavidMason Yes I know, what I meant is that now I know I’ve tried the right command :slight_smile: