MacInTouch Amazon link...
Channels
Apple, Products
Update: Well, I gambled and - so far (knock wood) - may have won. I wiped the drive and reinstalled from the recovery partition, then did a straight up migration - using Migration Assistant - from the clone I had just created. This clone, by the way, as I have said, reflected the true size of data I had - about 400 TB used.

Upon finishing and rebooting, etc., the SSD original startup drive (the problem drive) is now reporting about 600 GB available. Not only that, but for a double bonus, Adobe CS 6 and Office 2011 seem to be still registered, which does not happen with every migration. Since I don't use them anymore, I'm tempted to just delete them, but I'll see. Signed in with Adobe CC and Office 365, did the Dropbox, Boxcryptor and VPN shuffles, and I'll probably run into a few other things, but it's been remarkably smooth so far, in terms of psychic pain. I was preparing to give up my night for this.

I'll keep a close eye over the coming days and weeks. If there's any creeping data abnormalities, etc., I may go to the more drastic option, which would be to wipe it and reinstall just what I need, keeping it clean and mean, and then moving my files over by hand, the old fashioned way. We shall see. So far, though, so good.
 


Another update. It's only an hour or so later, and I'm hoping everything has synced - and I could be watching this pot too closely - but available space has decreased by about 4 GB without my having done anything.

Again, not configured for Time Machine, so I don't think it's taking snapshots. I keep checking Activity Monitor, but I don't see anything nefarious-looking at the moment. I guess I'll just keep watching it and see. Could there be some kind of memory leak happening with the Finder?
 


One more update. It may have stabilized. A few hours later, the apps have all caught up, I have restarted a few times, and it seems like it's only lost a few GB since the install.

Net result of the day is I gained back 105 gigabytes of space that I could not account for, see, or recover in any other way. I'll keep watching. Now, I have to get some work done.
 


... Again, not configured for Time Machine, so I don't think it's taking snapshots....
"Not configured" means Time Machine is turned off (automatics off) or just that there is no current target disk attached?

I'm not 100% sure about Carbon Copy Cloner, but it is also probably using snapshots. If you 'clone' from APFS to HFS+, you won't get a 100% exact clone, because HFS+ can't do what APFS does. One of those things is snapshots. All your 'current' files will (should) copy over, but can't represent the APFS 'copy on write' sharing in HFS+, so the 'copy' process should ignore snapshots.

One CCC FAQ on data size differences (because of exclusions and other factors:
Bombich Software said:
Another FAQ on CCC usage of snapshots
Bombich Software said:
Another CCC FAQ notes that APFS snapshot doesn't 'solve' the backup problem (only primarily saves space on the original data volume). However, it is useful in the backup process to get a coherent picture of the file system. If there are apps with files open or changing during a relatively long backup process, it is better to get a fixed-in-time set of files.
 


Ric Ford

MacInTouch
"Not configured" means Time Machine is turned off (automatics off) or just that there is no current target disk attached?
The tmutil terminal command may be helpful here, and there are third-party apps that may also help - for example, Disk Sensei has a switch to enable/disable local Time Machine backups (under Tools > Optimize).
Bash:
man tmutil

tmutil listbackups

sudo tmutil disable
sudo tmutil enable

sudo tmutil disablelocal
sudo tmutil enablelocal
 


"Not configured" means Time Machine is turned off (automatics off) or just that there is no current target disk attached?

I'm not 100% sure about Carbon Copy Cloner, but it is also probably using snapshots. If you 'clone' from APFS to HFS+, you won't get a 100% exact clone, because HFS+ can't do what APFS does. One of those things is snapshots. All your 'current' files will (should) copy over, but can't represent the APFS 'copy on write' sharing in HFS+, so the 'copy' process should ignore snapshots.

One CCC FAQ on data size differences (because of exclusions and other factors:

Another FAQ on CCC usage of snapshots

Another CCC FAQ notes that APFS snapshot doesn't 'solve' the backup problem (only primarily saves space on the original data volume). However, it is useful in the backup process to get a coherent picture of the file system. If there are apps with files open or changing during a relatively long backup process, it is better to get a fixed-in-time set of files.
Thanks, Lyman. I'll look at those links later. "Not configured" is Apple's terminology, and it will appear when you click the Time Machine icon in the menubar if you have not set up a Time Machine drive or disk. I'm not sure if it can be "turned off", but, if you have not selected a disk, it's essentially not working. Now, whether or not it's still taking snapshots is something I do not know. I'll look into the CCC snapshots, as well.

Like I said, it seems to have stabilized for now and the "remaining space" has not changed much in either direction. I was half thinking that the initial few GB usage may have been Spotlight's initial indexing, but I don't know how much space that database takes up.

Either way, I appreciate the feedback and the links and will report back if I figure out anything else.

Thanks.
 


You want to hear something really amazing?

I got a new machine. Migrated from an external hard drive. Set it up yesterday. All was fine.

Decided to clear some disk space today and tossed about 100 GB worth of stuff - this is a different machine, mind you, then the one I describe above - and guess what? Nothing changes on the "available space" readout at the bottom of any Finder window. I restarted. I did what I did previously.

I'm now about to toss out stuff from the migration source disk and then do it again. In the meantime, I'm reinstalling the OS. Not really thrilled with this waste of time. I have never run into this kind of behavior in a Mac OS Finder - going back to System 6, in the dark ages. Am I the only one here who has dealt with this?
 


Decided to clear some disk space today and tossed about 100 GB worth of stuff - this is a different machine, mind you, then the one I describe above - and guess what? Nothing changes on the "available space" readout at the bottom of any Finder window. I restarted. I did what I did previously.
It was suggested earlier: This could be the result of local snapshots that are made on APFS volumes. When you delete files, they will remain available in the snapshots till removed. The system should purge the space occupied by the snapshots, oldest first, when that space is needed.

You can simply check the existance of snapshots. In Terminal enter
Bash:
tmutil listlocalsnapshotdates
That will give you a list of dates of the snapshots on all local disks.

A better explanation about snapshots on APFS is given here:
Lifewire said:
Though Time Machine is used to view the snapshots and to return to a previous state, the snapshots are taken always on APFS volumes, without user intervention and whether or not Time Machine is set up.
 


Ronald, I was aware of that earlier suggestion. It didn't seem plausible here unless the snapshots came over via Migration Assistant. How else would there have been time to create 100 gigabytes worth of snapshots? And, more to the point, why does my "available space" at the bottom of every Finder window not reflect any changes when I toss significant amounts of data?
 


Making a snapshot does not take much time and it takes very little space. Files are not copied, only extra access points to the files are created. When you delete files after a snapshot was created, only the representations of the files that you see in the Finder are deleted. The files themselves will remain on the volume as part of the snapshot. Only when the system reclaims that space when it is needed, the snapshot is deleted also.
 




I just had a similar problem. My external APFS Thunderbolt SSD suddenly went from almost 200 GB free to 69 GB free in the Finder Get Info. A Carbon Copy Cloner clone to an HFS+ drive of the same size showed 180 GB free.

tmutil showed only snapshots from yesterday and the day before. DaisyDisk in trial mode showed that the System segment was hugely bloated, but snapshots took up only a small amount of it. Most of the rest was labeled "hidden." I couldn't find any helpful information on that, and the clone booted and ran as expected, so I reformatted the SSD to HFS+ and restored it from the clone with CCC. The free space was back.

Maybe the APFS drive was behaving normally, but the mysterious loss of free space made me uneasy. At my age, I have little enthusiasm for solving obscure problems. I just want the Mac to work.
 


Hmm. After rereading the comments by Ronald P.R. and the link he provided, I know what happened to my drive.

When I installed the latest update to iTunes, my podcast default preference for downloading episodes flipped to On. iTunes proceeded to download a boatload of old episodes. I deleted them but did not realize that the local snapshots would hold onto them until the space was needed. Mystery solved, I think.
 


Here is an article about how to reclaim drive space by thinning Apple File System snapshot backups:
Thanks for sharing the link Ronald. The
Bash:
tmutil thinlocalsnapshots
thinning command recovered several gigabytes of free space on my macOS 10.13.6 system.
 


KJM

I had a similar loss of space on my internal SSD (APFS). About 20 GB were missing, compared to my "normal" state. I think it happened after the crash of an application.

I checked the size of snapshots with Carbon Copy Cloner, but it did not match well.

I then ran the good old Unix maintenance scripts, and the maintenance worked immediately; I have got my 20 GB back.

Obviously this loss of space was caused by temporary cache files that were not closed and deleted properly when that application had crashed.
 


I tried the tmutil thinlocalsnapshots command, but I'm getting the response "Unrecognized verb". Any idea what I'm doing wrong? (I'm running Sierra 10.12.6.)
 


FYI, Network Appliance (the first company I've seen to implement snapshots) has a great whitepaper on the technology.

I don't know the details of NetApp's "WAFL" file system or APFS, but they seem to be describing the same (high level) concepts.
 


I tried the "tmutil thinlocalsnapshots" command, but I'm getting the response "Unrecognized verb". Any idea what I'm doing wrong? (I'm running Sierra 10.12.6.)
I believe "local snapshots" is only a feature starting with High Sierra and its APFS filesystem. So the Sierra Terminal application wouldn't have access to that command.
 



Another interesting data point. Just ran Carbon Copy Cloner - which I have used since 2003 - and noticed, for the first time, a message at the start of the task "Thinning snapshots" and then "Removing Snapshot from July 16th" or something like that. 6 GB were freed up. Interesting.
 


Another interesting data point. Just ran Carbon Copy Cloner - which I have used since 2003 - and noticed, for the first time, a message at the start of the task "Thinning snapshots" and then "Removing Snapshot from July 16th" or something like that. 6 GB were freed up. Interesting.
Carbon Copy Cloner uses snapshots on APFS volumes in two ways:

On source volumes, it will create snapshots, deleting the older ones according to a configurable retention policy, so you can recover files without needing to hit up your backup volume. When making a backup, the source is the snapshot, to ensure that nothing changes while the backup progresses. If you have source snapshots disabled, then backups are made from a temporary snapshot, which is deleted when the backup completes.

On destination volumes, the Safety Net feature uses snapshots instead of copying old versions of files to a special folder (the way it works on CCC4 and for non-APFS destinations). Older snapshots are deleted according to a configurable retention policy.
 


Another interesting data point. Just ran Carbon Copy Cloner - which I have used since 2003 - and noticed, for the first time, a message at the start of the task "Thinning snapshots" and then "Removing Snapshot from July 16th" or something like that. 6 GB were freed up. Interesting.
There is a ton of info at the link David just posted re: CCC and APFS snapshots. One important thing to note is that snapshots are automatically enabled, but they can be toggled on or off in CCC's settings. Anyone who uses CCC and sees a discrepancy in the amount of free space that Finder reports for an APFS volume should double-check that setting in CCC.
Bombich Software said:
CCC considers snapshot support on an individual volume basis. Snapshot support is automatically enabled for a volume when you select that volume (or a folder on that volume) as a source or destination to a CCC backup task. If you prefer that CCC does not automatically enable snapshot support for source and destination volumes, you can disable that behavior in CCC's Preferences window.
 


KJM

Carbon Copy Cloner uses snapshots on APFS volumes in two ways:
To be clearer: Carbon Copy Cloner creates its own snapshots if that option is set (it is, by default) for the APFS volume. So you may discover that two kinds of snapshots exist: macOS snapshots and CCC snapshots. (I have disabled this CCC option in order to regain space.)

By the way: macOS High Sierra snapshots are very helpful when you want to get back to a disk state of some hours ago. If you want to make use of this feature, boot from the Recovery partition and use "Recover from Time Macine" — even when no external Time Machine volume is attached. Then you can choose which snapshot you want to recover from, and it takes only seconds to do so.
 


And, on an unrelated note, while I'm griping about "Finder follies," why does it take so long now for volumes to unmount after I have ejected them? I am talking about almost any external, whether they are part of an enclosure or just individuals. And this has been bad for at least two years, going back a few iterations of the OS. Just had to gripe.
 


And, on an unrelated note, while I'm griping about "Finder Follies," why does it take so long now for volumes to unmount after I have ejected them? I am talking about almost any external, whether they are part of an enclosure or just individuals. And this has been bad for at least two years, going back a few iterations of the OS. Just had to gripe.
Me too. It happens about 20 percent of the time. Yes, the external volumes.
 


Ric Ford

MacInTouch
Why does it take so long now for volumes to unmount after I have ejected them? I am talking about almost any external, whether they are part of an enclosure or just individuals.
I see this, too. I have a hypothesis that it may be related to macOS caching of disk contents in RAM and needing to write out the cache, but I have not tested/proved that hypothesis.
 


I see this, too. I have a hypothesis that it may be related to macOS caching of disk contents in RAM and needing to write out the cache, but I have not tested/proved that hypothesis.
I, too, had this problem with an assortment of external hard drives and traced the issue to Spotlight indexing the drives. Simply, the drives wouldn't be unmounted until Spotlight had finished indexing, which, if copying a large amount of files, could be a while.

I excluded the drives from Spotlight indexing, and they now all unmount within a few seconds.

Of course, if you want the contents to be indexed, this may not be a viable solution, but I've never found Spotlight to be either reliable or intuitive to use.

It does beg the question why Apple couldn't have just added a few extra lines of code to tell Spotlight to suspend indexing when the drive is ejected, but issues with Apple software quality have been well covered in these forums.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts