@oO.o I want to try and articulate better what I’m trying to do. I installed tree and an example path is android backups:
Further upstream of that is ‘Share Drive’, and then upstream of that is ‘Pool1’
Each of those folders have (should have) files found within, but what rsync did was put those files in a hidden ~tmp~ file.
For example that phone backup, going into the Apps folder:
So rsync moved over all the files from FreeNAS to the backup Pi that should be in :/mnt/backup/Pool1/Share Drive/phone backups/MobileBackup/App, but into the temporary hidden folder “~tmp~”
When all files were done for the whole rsync job, per the delay-update argument in the man page it was then to:
This option puts the temporary file from each updated file into a holding directory until the end of the transfer, at which time all the files are renamed into place in rapid succession.
It did the put into temp file part, but not the rapid succession of moving them out of it and into their normal folders.
So I have this huge file structure (using tree starting at Pool1 was a never ending scrolling print I had to ctl C out of). where in every directory is a ~tmp~ folder ‘hiding’ the files.
There must be a clever way, be it rysnc command or bash script, to have the system go into every path starting down from Pool1, crawl into every folder, look for ~tmp~, if found grab contents within ~tmp~, move it up one folder path (ex: apps/~tmp~, move everything from apps/~tmp~ to /apps). It would need to do this throughout the whole… tree.
This way I don’t have to nuke what I already moved over. But if this somehow also breaks how rsync hashes the contents to know the delta for a subsequent backup- meaning it might not see any of the data as already have been moved and will just move all of the data over again, I might as well just nuke from orbit and run again (this time I removed the delay-updates argument)
