Four ways to relocate index folder/disk but which one is suitable and under what situation?

It seems various threads have suggested four feasible methods re the relocation of index folder/disk in DT3. I wonder whether one way is more suitable than the other for a particular situation and how those methods may affect the sync of DT3 among computers and sync among DT3 and DTTG. Maybe DT can consider posting a sticky topic to explain the pros/cons OR just one/two most common/safest/easiest methods after the release of the final version?

Three common questions for the below-mentioned 4 methods: Q1: are these methods also apply to the partial relocation of sub-group/sub-folder under index group/folder? Q2: are these methods reversible? Q3: what will happen to the relevant item links (annotation notes, link among items in DT), and replicants from the items of the original index group?

The “folder” here refers to a top-level index folder, but it seems to me that the process is similar/identical to disk.

(1) Using import&re-index: Import the original index folder, re-export the group to a new location, re-index the folder from the new folder location. If success (check the content and verify), delete the previously imported group.

(2) Using Aliases. Move the folder in Finder to a new location. Create an alias of the relocated folder And put the aliases to the original folder’s location.
Q4: Is this method workable ONLY when there is no change in the name of the top-level folder and the hierarchy of folders within?

(3) DT3 only: Index to new empty folder and move. Create new but empty folder/s in the planned new Finder location, index those new folder/s into DT3. Within DT3, move the items from the original index group to the new index group, delete the old index group.

(4) DT3 only: Script to change the path of the index folder. Move the folder in Finder, get the new POSIX path. Use a script, replace the original POSIX path of the index items within DT with the new path.
Q5: Is this method more flexible and can apply to any combination of selected items and groups?

I’m sure that I have missed other feasible methods and essential questions. This post is meant to be a starter for those (like me) who need to re-organise their folder/s in MacOS occasionally.

The 3rd and 4th methods are now the preferred ones. The script supports any combination but I would recommend it only to advanced users as scripting can’t be undone and as it’s easy to break paths that way.

Honestly, these methods are so fragile, as to make me avoid indexing folders unless I absolutely have to. A common example: I’ll index a folder of materials related to a project I’m writing about within the database. When that project is done, that folder will usually get moved to an archive folder or drive — but now that link to the DT database is broken. Yes, I remember that I have to move that folder via DT, but if I forget, that link is simply broken.

I would love to see a solution similar to what Adobe software does. First, the program has a palette that shows all links to external resources. Then, when you open the file, if it notices that an external resource is missing, it asks you to find it. I know this is comparing apples to oranges, but I wonder if a similar tool could be added to DT.

1 Like

In this case, the remedy is to use method (4) and you can repair all links in one go? (just asking…)

EDITED: Perhaps the script in (4) can be modified to a more user friendly approach by (1) user choose the “old” group (with broken links), call the script from menu, the script will pop up the Finder and let user to choose the new top folder. All POSIX path repairing will be conducted at the backend. This will avoid the mistakes coming from wrong path entry.
Then again, there are two sides of the argument. A more convenient feature may encourage user to be “very/too” experimental and creates more link issues and support requirements.

Yes, this would fix it.

If that was possible, it would be great. As @cgrunenberg says, the current version is for advanced users.

Honestly I feel without the “convenient” option, indexing is too susceptible to unexpected problems to make it a reliable tool.

et al:

My personal take is that indexing should be approached with forethought and very careful consideration. It is not the panacea for all situations.