I recently moved a large group of files (many directories) to iCloud Drive - so they'd be available on my other devices - and watched as they all uploaded...
Then did some testing to confirm - only to find that many files never did upload. (I tested over the course of _weeks_; this was not an issue of bandwidth.)
I compared (using diff) the state of the Mac on which the files were first moved into iCloud, versus the files on another Mac which was freshly set up with iCloud, so got them only via iCloud sync. (I also spot-checked, using the web interface for iCloud Drive.)
So I started trying to determine why. It's a somewhat lively source of discussion - among those who've actually noticed the problem -- which is almost entirely invisible, unless you go looking for it. :/
Much of the discussion was the expected (unfortunately) reflexive "have you tried turning it off and on again?" - about killing processes, deleting various files (ex: ~/Library/Application Support/CloudDocs) and rebooting - and, as expected, none of that helped.
However, the clue I needed was in this Ask Different post: iCloud Drive stuck on “Waiting to upload”
(BTW: The only way to see that "Waiting to upload" message, is to first already know that there's a file in that state; then hover over the tiny dotted line cloud icon next to it, in Finder. Nearly-invisible errors are a terrible thing. And, unfortunately, info about iCloud Drive status icons is hard to find, and somewhat limited. Note also: Contrary to the info in the above link, the icons are for iCloud Drive, regardless whether the sub-feature of Desktop and Documents is specifically enabled - in my case, that's disabled.)
With the info gained above, I see that in all the cases that I'm dealing with - of a file stuck in "Waiting to upload" - each of them has an extended attribute com.apple.metadata:kMDItemWhereFroms which is _very large_.
It does not contain, as expected, a URL of where the document came from - but it actually apparently contains another copy of the full document. :/
This metadata is also apparently unexpected / dysfunctional, since even though it shows via ls or xattr, the mdls command ignores it.
So now I'm even more sure, that this extended attribute is disposable. One last question: Does removing it, update the "modified" timestamp (which is useful info that I want to preserve)? Thankfully, some testing shows that the timestamp is unchanged.
So what I did (standard disclaimers apply - use at your own risk) to find and fix all such files in my iCloud Drive directory, was something like this:
-type f \
-xattrname com.apple.metadata:kMDItemWhereFroms \
-print | while read -r thePath; do
testVal=$(xattr -lp com.apple.metadata:kMDItemWhereFroms "$thePath" 2>/dev/null | \
head -5 | tail -4 | sed 's/^.* |//;s/|$//' | tr -d '\n')
if [ $(echo "$testVal" | grep -E -c 'data:(application|attachment)') -gt 0 ] ; then
echo 'BEFORE:'
ls -l@ "$thePath"
xattr -d com.apple.metadata:kMDItemWhereFroms "$thePath"
echo 'AFTER:'
ls -l@ "$thePath"
fi
done
