I performed a clean installation of 16A201w and allowed Setup Assistant to use iCloud Drive Desktop and Documents Folders.
Twelve minutes after login: nothing in either folder. No on-screen explanation for the emptiness, which is potentially disconcerting, but I didn't expect 16A201w to be polished.
After maybe ten of those twelve minutes, a dotted cloud icon appeared against both folders in a Finder column view of iCloud Drive. With icon view there's no such hint.
A Finder view of
All My Files showed a handful of files from a container for one iCloud-enabled application, so I'm certain that data is downloading.
Postscripts
The update to Developer Beta 8 (not a golden master)
is installing. I'll add to this post some time after that and all other updates are installed.
https://forums.macrumors.com/posts/23337636 under
How Stable is it? mentioned a ~1 GB test set of data. Some of what follows suggests that truly, the test set comprised more than
2 GB of data. Sorry for the mistaken recollection – in the weeks that passed whilst waiting for upload to complete, I probably lost all interest in measurement :-/
Loss of data
.textClipping files
Maybe excluded because the data fork of a Mac OS X text clipping is, by design, zero bytes …
Some time later, at the Mac where the data originated, it seemed to me that the exclusion no longer applied. More specifically: there was no icon or other form of warning to suggest a problem with acceptance of text clippings.
Now – since I performed a clean installation of the OS and entrusted the contents of my Desktop and Documents folders to iCloud Drive – it seems that all clippings were effectively lost. Thankfully the data is elsewhere (not entrusted to Apple's services alone) but I always treat
silent loss of data, or metadata, as unacceptable.
Code:
sh-3.2$ date ; uptime ; sw_vers
Sat 10 Sep 2016 14:02:32 BST
14:02 up 3:38, 2 users, load averages: 1.53 1.51 1.42
ProductName: Mac OS X
ProductVersion: 10.12
BuildVersion: 16A313a
sh-3.2$ cd /Users/grahamperrin/Documents
sh-3.2$ find . -name "*.textClipping" -print
./2008/SuperDuper! and Data.fs/Last login- Tue Sep 23 22-44.textClipping
./2008/SuperDuper! and Data.fs/SuperDuper! and Data.textClipping
sh-3.2$ cd /Volumes/Graham/gjp22/Documents/2008
sh-3.2$ find . -name "*.textClipping" -print
./[omnium-~] admin% sudo :Appl.textClipping
./CAUTION with the msg4 address.textClipping
./CENTRIM-C/httpd log tail.textClipping
./CENTRIM-C/system.log tail.textClipping
./GCC.textClipping
./Getting distribution for 'py.textClipping
./shortly before 13-51 --http-.textClipping
./SuperDuper! and Data.fs/Last login- Tue Sep 23 22-44.textClipping
./SuperDuper! and Data.fs/SuperDuper! and Data.textClipping
sh-3.2$
In that example:
- at ~/Documents/2008 only two .textClipping files survived (within a directory that was interpreted as a bundle because long before upload to iCloud Drive, in Finder I allowed the name of the directory to end with .fs)
- neither of the surviving .textClipping files has any content.
… although zero-data-byte .webloc (Web internet location) files – produced by drag and drop from apps such as Safari – are eligible (but presented as binary files in the web interface to iCloud Drive; the web browser can not tell the location until after Mac OS X has downloaded and decoded the content).
Now I realise: the Web internet location files stored by iCloud Drive are
useless when opened at a Mac other than the one where the files originated. Safari launches but there's nothing more than an empty window to the web, and then Finder is brought to front.
Given those two examples of loss, it's resasonable to assume that some other types of file are subject to dataloss when entrusted to Apple's service. Did anyone test
.pictClipping (Picture Clipping) files?
I hope that someone noticed bugs such as those, and fed them to Apple in good time …
Afterthought
Maybe those dataloss bugs are already fixed. It's possible that my data was uploaded, and suffered from the losses, before fixes were made.
Rough notes to self
2016-09-09 around 07:45:
- 54 aliases, 4 applications, 13,090 documents, 1,591 folders
- 2,482,631,535 bytes (2.52 GB on disk)