MacInTouch Amazon link...
Channels
Apple, Products
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.
 


I don't think it is Spotlight alone, as I still have the slow dismount problem despite excluding frequently used network shares from Spotlight. Sometimes clicking the eject symbol next to the name of a mounted disk in the sidebar of a Finder window works when command-E fails. This is the main reason why I invested in licenses for Path Finder, which seems a lot faster to eject disks. Now, if only network file copies would run as fast in Path Finder as in the Finder.....
 



You might take a look through Path Finder preferences, if you haven't already. I see an option for "Show icon previews", for example, which may have an effect on performance.
Yes, I have that switched off. I wonder if the slow file copying is due to the fact Path Finder uses AFP connections? I noticed this when doing a Get Info in Path Finder on a mounted share - it shows the URL as

afp://accountname@servername._afpovertcp._tcp.local/diskname
 


And so my two issues coincide here. I have talked on another thread about creating a bootable external drive for my 2018 MacBook Pro. I discovered that it needs to be APFS and an exact clone of the startup drive. Follow me? Ok, so I create an SSD, APFS-formatted clone of my startup drive.

At the bottom of a Finder window in the clone, it said there were 555 GB available.

I throw out 300+ GB of extraneous files.

At the bottom of the Finder window, it now says there are still 555 GB available.

I then start to copy items to it, and the "space available" number diminishes in real time.

This has nothing to do with snapshops, okay? It is simply not recording data that I trash. Why does it not record when I toss large amounts of data?

I'm going to give it a few hours to see if there's any housekeeping it needs to perform. Then I'll perform a clone of the clone, and I'm certain it will only clone what's on there, and I'll be left with the accurate amount of free space.

My problem persists, but this is on a different machine. I may even call the morons at Apple again. This one is starting to p*ss me off.
 


Path Finder has a preference under Features > File Operation to verify copied files. That slows copying quite a bit, but I use it for critical operations such as backing up my virtual machines and updating the firmware on my Kindle Paperwhite.
 


This has nothing to do with snapshops, okay? It is simply not recording data that I trash. Why does it not record when I toss large amounts of data?
Have you used Carbon Copy Cloner to view the snapshots that are being kept on your APFS boot drive, or to confirm that there are no snapshots? I've seen you state a few times that this has nothing to do with snapshots, but I have not seen you post the method you used to confirm this.
 


Path Finder has a preference under Features > File Operation to verify copied files. That slows copying quite a bit, but I use it for critical operations such as backing up my virtual machines and updating the firmware on my Kindle Paperwhite.
I have that off, too! Version 7 of PathFinder was just as fast as the Finder, and this slowness appeared with v8. I'm hoping it will get ironed out as the new version matures - it seems to be updated every couple of weeks or so, so the author must be working actively on polishing it.
 


I throw out 300+ GB of extraneous files. At the bottom of the Finder window, it now says there are still 555 GB available. I then start to copy items to it, and the "space available" number diminishes in real time. This has nothing to do with snapshops, okay? It is simply not recording data that I trash. Why does it not record when I toss large amounts of data?
Because you haven't emptied the trash (I assume, since it's not in your list of actions). When you empty the trash, the available space will increase.
 


... This has nothing to do with snapshops, okay? It is simply not recording data that I trash. Why does it not record when I toss large amounts of data?
Snapshots are hidden by default. In order to completely rule them out, you need to check that there are none.

I haven't done a lot of experimenting with macOS 10.13 (no spare SSD lying around at the moment), but this article suggests that Apple may silently invoke a snapshot on a major OS upgrade. It isn't just overt Time Machine (or cloning alternatives) that can invoke a snapshot.

https://www.lifewire.com/roll-back-apfs-snapshots-4154969

Essentially, Apple is working to get to similar functionality of Window's restore points. If you have restore points, then the "original" OS image should one of those restore points by default. (If can't go back to the "beginning", then what is the point of restore?)

This is something that probably should be some mode of "Disk Utility" (or Apple creating an "AFPS snapshot" viewer utility). Windows has a "Control Panel" tab that allows the admin to set a percentage of the disk that restore points take up. For users with substantively larger storage drives than their normal consumption footprint, this pragmatically isn't a problem.

Short-term, Apple could probably do something to make the terminal command
diskutil apfs info
a bit more informative in relation to snapshots. There should be a way to get a summary of everything in the APFS containers attached to the system currently running on Mac (an enumeration of the snapshots being one of those attributes).
My problem persists, but this is on a different machine. I may even call the morons at Apple again. This one is starting to p*ss me off.
This new system simply requires a small shift in the mental model. If you apply an old mental model, something that doesn't match that doesn't make the creators of the new thing 'dumb'.

This is a bit bigger of a shift but similar to when Apple added the [invisible] recovery partition to installs by default. A single partition was not going to be matched with the whole drive.

So, if looking to install a minimal core macOS image on systems, you should start with that, not put something that is big and then try to shrink it down. (Clone this smaller one and start from there as a minimal image.)
 


I don't think it is Spotlight alone, as I still have the slow dismount problem despite excluding frequently used network shares from Spotlight. Sometimes clicking the eject symbol next to the name of a mounted disk in the sidebar of a Finder window works when command-E fails. This is the main reason why I invested in licenses for Path Finder, which seems a lot faster to eject disks. Now, if only network file copies would run as fast in Path Finder as in the Finder.....
I have the problem of slow dismount of external drives (SSD or hard disk drive, USB3 or FireWire), but I also get 3 successive dialog boxes including 'force eject', which I dismiss every time. Not a problem, really, but a pain. My workaround is to open 'Clean My Drive' in the menu bar and click the eject symbol next to the drive, and it dismounts in a second.
 


I have used Path Finder for what seems like forever. It has had every power tool I could possibly want (and a few that I don't find personally useful), and allowed me to get my work done easily and effortlessly.

That is, until yesterday. I've been using PF8 since mid-summer. I've read all the discussion upthread about a new code base, and the need to move this utility forward. I've found niggling little issues with that new code base, and a few UI irritations that are related to the new "modules" system the developer is promoting. (The most irritating of these is that the module for the move/copy bin seems to close whenever it feels like it, and you must open it before you drop a file on it. The second-most irritating is the inability to retain Favorite paths in a sidebar.)

But yesterday, along with the advent of Mojave, Cocoatech pushed out a quick succession of updates dealing with issues related to "dark mode." I don't allow automatic updates, but apparently I only installed the last one.

The last one they pushed out broke the ability for all other users to manipulate files while in column view. And, it wasn't a simple "can't do it" break. Instead, clicking on a folder would somehow "pop" it into the folder above it in the list. The interface would flash when this happened, but not immediately refresh.

And, that's how my Dropbox folder landed in my Amazon Drive folder.

The immediate effect was that Dropbox could no longer link to its folder on my iMac. It wasn't a simple matter of dragging it back, because all the files that were now on Amazon Drive had lost their Dropbox "blessing." Amazon dutifully synched most of it, because it took me a few minutes to realize where my 142 GB of data had gone.

So, I have removed PF8 from my system and restored PF7. The "Hazel" assistant very helpfully offered to remove the PF8 support files, and after a restart and reauthorization with a PF7 license I was back in business. Honestly, I'm also breathing a big sigh of relief. The PF7 UI is not the most beautiful thing in the world, but it works, and it does not have a bunch of unwelcome surprises in it.

I've let the developer know that I support the general reasons for updating PF, but I won't reinstall it until it can be called a stable release. Right now, it can't.
 


Ric Ford

MacInTouch
So, I have removed PF8 from my system and restored PF7
I tried Path Finder 8 when it came out, after using Path Finder 7 for a long time, and it just wasn't working well, so I, too, reverted to Path Finder 7 and have stayed with it all these months (running macOS 10.12 Sierra).
 


I finally gave up Path Finder completely. I'm back to Finder. I haven't used Finder for many years, since before Finder got tabs. I participated in the Path Finder beta program, provided feedback, etc. and just got tired of the waiting. So... I've reverted to Finder and will be building Quick Actions to take over for Path Finder functions. The only one I've built so far is the 'Open Terminal Here' item. I also have DropZone installed from Setapp to give me the drop bar functionality. We'll see how it all goes.
 


I've used Path Finder since version 7; the transition to version 8 has indeed been rocky. Adding to the things already mentioned that still don't work, that I used frequently in version 7: the local Terminal module, File Compare, Find. Find brings up files but does not supply the path to them, meaning that one must click on the file, opening a new Path Finder window. Support has said they're eliminating Find as it has been and making it accessible in any window, whatever they mean by that.

I'm sticking with it for now, because I find Finder constrained; that said, with Mojave Dark Mode, at least I can see it now (age 70 eyes mourning Mac display for a few years).
 


I tried Path Finder 8 when it came out, after using Path Finder 7 for a long time, and it just wasn't working well, so I, too, reverted to Path Finder 7 and have stayed with it all these months (running macOS 10.12 Sierra).
Yes; I should have mentioned that I am also on Sierra. I’m really feeling for folks who can’t revert to Path Finder 7 because they have migrated to Mojave. The Finder (which in concept I have always loved, but in practice have loathed since the first release of Mac OS X) did not look any better to me in the brief interval during which I was recovering Path Finder 7.

My only other exposure to Finder all these years has been when I wanted to use AirDrop, which I think is really underrated. For that one purpose, Finder is fine.
 


The App Store has a long list of batch file-rename utilities, most of which cost up to $20. You may not need any of them. I just found out that you can do almost everything those utilities can do, but you can do it directly in Finder, to a single file or to a batch.

You can index, change, add to an entire list of files by selecting the list in a Finder window and then clicking on File Rename. A window opens and you indicate your options. Finder does the rest.

For example, a client requires me to add my initials at the end of files I have modifed for him, in the form "_BE".

Finder Rename lets me apply _BE at the end of every filename (but before the extension) in the selected list of files.

TidBITS has a clear description of this process.
 


The App Store has a long list of batch file-rename utilities, most of which cost up to $20. You may not need any of them. I just found out that you can do almost everything those utilities can do, but you can do it directly in Finder, to a single file or to a batch.
{snip}
TidBITS has a clear description of this process.
That's a great tip! I hadn't been aware of it until I saw the TidBITS article, myself.

That said, I will put in a plug for a family of complementary utilities by Frank Reiff at publicspace.net, some of which date back to Classic Mac OS days. Especially for people who like to manage photo libraries or other file collections by hand, these tools have a lot of power (like regex support) but are simple to use:
They're the kind of tools that you may go a long time without using, but when you have the need for them, they really scratch the itch. Each tool is very focused on doing a few things very well, rather than trying to cram too much into one package, which is a philosophy I've come to appreciate. Around $35 to buy all three as a bundle. (Disclaimer: I have no affiliation with Publicspace, aside from having been a customer of theirs for a very long time.)
 


On the subject of batch renaming: I have been using NameMangler, which has worked well for my purposes.

I use it to apply a camera-specific prefix to my dSLR images and change the case of the extension to lowercase. But it can clearly do much more. I’m ashamed to say that it took me a while to realize that I could add steps to an action… RTFM, indeed.
 


I just found out that you can do almost everything those utilities can do, but you can do it directly in Finder, to a single file or to a batch.
For a better interface and, I think, even more powerful renaming options, use Automator. It's present in your Applications folder.

For certain tasks most commonly related to image files, GraphicConverter has amazing batch capabilities, including renaming.
 



I work with large video files, some of which are 40 GB to 100 GB. For the last few years, I have noticed a problem that the Finder stops copying and reports an error when copying files larger than about 50GB - especially to external drives. Does anybody else encounter this problem? This is often repeatable on several computers and several macOS (High Sierra and Mojave). However, this might be limited to my setup. So do you have a Finder copying issues in any of these circumstances?

1) From internal to external drive. Anyone encounter copying 50+GB files this way?
2) From external to internal?
3) Across a network using AFP to an internal drive?
4) Across a network using AFP to an external drive?
5) Across a network using SMB to an internal drive?
4) Across a network using SMB to an external drive?
 


Ric Ford

MacInTouch
I work with large video files, some of which are 40 GB to 100 GB. For the last few years, I have noticed a problem that the Finder stops copying and reports an error when copying files larger than about 50GB - especially to external drives. Does anybody else encounter this problem? This is often repeatable on several computers and several macOS (High Sierra and Mojave). However, this might be limited to my setup. So do you have a Finder copying issues in any of these circumstances? ...
It seems to me that using the Finder to copy huge files across a network would be pretty high on a list of possibilities with maximum masochistic potential. I'd suggest:

a.) trying Path Finder​
b.) using Rsync​
c.) using Synchronize Pro X​
d.) trying ChronoSync​
e.) using an external storage device directly connected via USB 3, FireWire or Thunderbolt​
 


Hello, DougW and Ric; last year I moved about 3 TB of satellite recordings from one hard drive to another one by using Carbon Copy Cloner with some specific rules. It worked great. At first I tried the Finder approach, but it didn't work.
 


It seems to me that using the Finder to copy huge files across a network would be pretty high on a list of possibilities with maximum masochistic potential. I'd suggest:

a.) trying Path Finder​
b.) using Rsync​
c.) using Synchronize Pro X​
d.) trying ChronoSync​
e.) using an external storage device directly connected via USB 3, FireWire or Thunderbolt​
In addition, Carbon Copy Cloner is a very effective GUI for rsync.
 


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

Latest posts