I put this in the other thread too but I’ll write it here too.
background requests are ENTIRELY MEANINGLESS TO THIS PROCESS. Having status --background be stuck is not that big a deal (oh also background requests for .cloudf files seem to just go from 0% to 100% instantly, the progress tracker is also meaningless and not actually proof of anything being wrong as I had first feared). the background requests are only for situations in which a new .cloud .cloudf or directory is needed. When everything is 100% fine the files just turn from white to pink to blue silently. This isn’t included in any status report, but it is something I can see by repeatedly using syncstate and targeting new directories as I follow progress.
Also the fact that this might take a long while is not really that big a deal, as I still have 3TB of data to upload to gdrive, which will take roughly 4 days.
The biggest deal isn’t re-indexing, so much as having to redownload 4TB of data, but so far it’s like you said. Actual data I’ve downloaded from ACD is being checked off by odrive as already perfect.
Also even though you said there isn’t going to be much of a savings in terms of metadata, it appears like there is actually a pretty big savings. It might not reduce the number of api requests I’m making to ACD, and I might get banned from ACD again for a day, but it’s running a lot smoother. My guess would be that when it wants to generate new .cloud or .cloudf files and it finds those files already exist, it can simply check them, instead of re-creating them, which I don’t know why, but is somehow a bit faster. I have proof of this too because it’s very rarely creating or modifying any of the .cloud files. I feared at first this was a problem, but I now see that a lot of .cloud files are being ACCESSED then left alone and turned blue by odrive. I was using -mtime not -atime in my find commands.