From Newsgroup: uk.comp.sys.mac

I have two identical really big disks, with identical contents.
The A disk is back-upped to the B disk, using SuperDuper.
Used to work fine.

Puzzle: Recently the B disk has about 100 GB less free space
than the A disk, which makes it completely full.
Both in the footer, and in Get Info.

Making invisibles visible, and comparing the directories
shows that the disks are identical in the names,
the number of folders, and in the folder sizes.
(so also in the sizes of the invisible Spotlight index files on both)

The B disk gets really full in the sense
that Finder writes to it are impossible,
and Finder operations become very slow.
After deleting some files SuperDupering is still possible though.

Disk Utility says that the disk is OK.
Restarting, or dismountng and mounting again has no effect.

What could be happening here, and what can be done about it?
(without wiping and rewriting everything, which takes a lot of time)

Jan


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: uk.comp.sys.mac

In article <1rm1uxw.e2aqbnmy2fubN%nospam@de-ster.demon.nl>,
J. J. Lodder <jjlxa32@xs4all.nl> wrote:

I have two identical really big disks, with identical contents.
The A disk is back-upped to the B disk, using SuperDuper.
Used to work fine.

Puzzle: Recently the B disk has about 100 GB less free space
than the A disk, which makes it completely full.
Both in the footer, and in Get Info.

Do you have any files with large blocks of zeroes? Or any files
that are hard links on one disk and separate files on the other?

Run du on each disk and see how the output compares.

-- Richard
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: uk.comp.sys.mac

On 19/11/2025 13:50, J. J. Lodder wrote:

I have two identical really big disks, with identical contents.
The A disk is back-upped to the B disk, using SuperDuper.
Used to work fine.

Puzzle: Recently the B disk has about 100 GB less free space
than the A disk, which makes it completely full.
Both in the footer, and in Get Info.

Making invisibles visible, and comparing the directories
shows that the disks are identical in the names,
the number of folders, and in the folder sizes.
(so also in the sizes of the invisible Spotlight index files on both)

The B disk gets really full in the sense
that Finder writes to it are impossible,
and Finder operations become very slow.
After deleting some files SuperDupering is still possible though.

Disk Utility says that the disk is OK.
Restarting, or dismountng and mounting again has no effect.

What could be happening here, and what can be done about it?
(without wiping and rewriting everything, which takes a lot of time)

Hi Jan

I asked Gemini (AI). This was the response:-

This is a classic puzzle related to **file system slack, hidden recovery partitions, or local snapshots**, which often appear differently in
reported free space versus visible file sizes.

Here's an analysis of what could be happening and what you can do:

-----

## EfoE Potential Causes

### 1\. **Local Time Machine Snapshots (Most Likely)**

If **SuperDuper** is configured to simply copy files, or if the backup
process involves a modern macOS (which it likely does since SuperDuper
is mentioned), the difference is often due to **Local Snapshots**
created by **Time Machine** on the *destination* drive (Disk B).

* **What they are:** Since macOS Sierra (10.12), Time Machine creates **local snapshots** (copies of files that have been deleted or changed)
on any drive formatted as APFS or HFS+ that is *connected* to the
system, **even if that drive isn't the primary Time Machine backup
drive.** These snapshots are temporary and automatically deleted when
space is needed, but **Finder and "Get Info" report the space they
occupy as *used space***, while the files themselves are not visible in
a standard directory listing.
* **Why Disk B has them:** When Disk B is plugged in and used (even
just as a target for SuperDuper), macOS may create these snapshots on
it. When SuperDuper is run, it might not be removing the existing
snapshots from previous runs.

### 2\. **Hidden Recovery Partition or Volume**

While you mentioned they are identical, there might be a difference in
the **volume structure** itself.

* **Recovery Volume:** If Disk A is your *bootable* primary drive and
Disk B was created by simply cloning the *contents*, the partition
scheme or the size of a **hidden Recovery Volume** on Disk B might be
slightly different or corrupted, leading to a small amount of space
being perpetually unavailable or misinterpreted. **However, a 100 GB difference points more strongly to the snapshot issue.**

### 3\. **File System or Journal Corruption**

* Although **Disk Utility** says the disk is **OK**, it sometimes
only checks basic structural integrity. A subtle corruption in the file system's **journal** or **catalog** file can lead to **orphaned data
blocks** that are marked as "used" by the file system but aren't
assigned to any visible file. This is less common but can account for
large amounts of "missing" space.

-----

## EfcaN+A Solutions and Steps to Check

The easiest way to confirm and fix the problem without wiping is to
**manage the local Time Machine snapshots**.

### Step 1: Check for Local Snapshots (The Confirmatory Step)

You need to use the **Terminal** to see and manage these snapshots, as
Finder hides them.

1. Open **Terminal** (Applications \> Utilities \> Terminal).
2. Use the following command to list all Time Machine local snapshots
on *all connected volumes*:
```bash
tmutil listlocalsnapshotdates /Volumes/B-Disk-Name
```
(Replace `B-Disk-Name` with the actual name of your B disk).

*If this command returns a list of dates, you have found the missing 100
GB.*

### Step 2: Delete the Local Snapshots (The Fix)

You can delete them all at once using the `tmutil` command.

1. In **Terminal**, use the following command to purge all local
snapshots on Disk B:

```bash
tmutil thinlocalsnapshots /Volumes/B-Disk-Name 999999999999 4
```

* **Note:** The large number (`999...`) tells Time Machine to
free up as much space as possible.

2. After the command runs, **check the free space on Disk B** in
Finder. The 100 GB should be instantly recovered.

### Alternative (If Snapshots Are Not the Cause)

If the above steps don't resolve the issue, the problem might be file
system corruption.

* **Run a Deeper Disk Repair:** Although Disk Utility said the disk
is OK, you can try running a repair from **Recovery Mode** or using a third-party utility.
* **Wiping and Rewriting (The Last Resort):** If the problem
persists, the most reliable fix is to **erase Disk B** completely via
Disk Utility and then run a fresh SuperDuper clone. This ensures a clean
file system structure. While you wanted to avoid this, a **corrupt file
system journal** often *requires* an erase for a full reset.

I recommend trying **Step 1 and 2** first, as Time Machine local
snapshots are by far the most common cause of this exact symptom on
modern macOS systems.

-----

Would you like me to find the specific commands for checking and
deleting Time Machine local snapshots if the disk is formatted as
**APFS** (which uses a slightly different `tmutil` syntax)?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: uk.comp.sys.mac

Richard Tobin <richard@cogsci.ed.ac.uk> wrote:

In article <1rm1uxw.e2aqbnmy2fubN%nospam@de-ster.demon.nl>,
J. J. Lodder <jjlxa32@xs4all.nl> wrote:

I have two identical really big disks, with identical contents.
The A disk is back-upped to the B disk, using SuperDuper.
Used to work fine.

Puzzle: Recently the B disk has about 100 GB less free space
than the A disk, which makes it completely full.
Both in the footer, and in Get Info.

Do you have any files with large blocks of zeroes?

No. Not that I know of.
It is mostly .pdf and .epub .jpg (or .zip and .rar)
All very compact file types.

Or any files that are hard links on one disk and separate files on the
other?

No, the B disk has never had files on it other than as BU of the A disk.
Some file may have gotten corrupted.
However, a systematic search for unique files (by name and file size)
between both disks doesn't yield any.

Run du on each disk and see how the output compares.

DU reports the same overall sizes as get info,
so 100 GB free for the A volume, 1 MB free for B,
(and file system OK for both)

Jan



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: uk.comp.sys.mac

In article <1rm2aio.1jdub951pqpp9nN%nospam@de-ster.demon.nl>,
J. J. Lodder <jjlxa32@xs4all.nl> wrote:

Run du on each disk and see how the output compares.

DU reports the same overall sizes as get info,
so 100 GB free for the A volume, 1 MB free for B,
(and file system OK for both)

Does df give the same result - same total size, but different
used/available?

Presumably you have unmounted and remounted them, or rebooted?
A deleted but open file could give that effect.

-- Richard

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: uk.comp.sys.mac

On 19/11/2025 13:50, J. J. Lodder wrote:

What could be happening here, and what can be done about it?
(without wiping and rewriting everything, which takes a lot of time)

1) Obvious but just in case: have you inadvertently partitioned drive B
and there's 100GB allocated to Bootcamp or left unformatted?

2) Is drive B formatted with a different file system and/or block size?

3) Unlikely: perhaps some bad sectors have been mapped out so the total
drive capacity has been reduced? Disk Utility will give you the drive's
SMART status
--
Bruce Horrocks
Hampshire, England
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: uk.comp.sys.mac

Bruce <07.013@scorecrow.com> wrote:

On 19/11/2025 13:50, J. J. Lodder wrote:

What could be happening here, and what can be done about it?
(without wiping and rewriting everything, which takes a lot of time)

1) Obvious but just in case: have you inadvertently partitioned drive B
and there's 100GB allocated to Bootcamp or left unformatted?

No.

2) Is drive B formatted with a different file system and/or block size?

The drives were bought together,
and initialised within an hour of each other.
HFS+ Guid partition table.

3) Unlikely: perhaps some bad sectors have been mapped out so the total
drive capacity has been reduced? Disk Utility will give you the drive's
SMART status

Not for externals.
BTW, actually I have three identical ones.
Both BU disks have the same problem,

Jan

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: uk.comp.sys.mac

On 20/11/2025 19:45, J. J. Lodder wrote:

Bruce <07.013@scorecrow.com> wrote:

On 19/11/2025 13:50, J. J. Lodder wrote:

What could be happening here, and what can be done about it?
(without wiping and rewriting everything, which takes a lot of time)

1) Obvious but just in case: have you inadvertently partitioned drive B
and there's 100GB allocated to Bootcamp or left unformatted?

No.

2) Is drive B formatted with a different file system and/or block size?

The drives were bought together,
and initialised within an hour of each other.
HFS+ Guid partition table.

3) Unlikely: perhaps some bad sectors have been mapped out so the total
drive capacity has been reduced? Disk Utility will give you the drive's
SMART status

Not for externals.
BTW, actually I have three identical ones.
Both BU disks have the same problem,

If both BU disks are affected then that suggests a SuperDuper issue.

If you are backing-up individual files then the space might be being
used for file version data so SuperDuper can keep track when there are multiple versions of a file?

Not sure how to test that, though.
--
Bruce Horrocks
Hampshire, England
--- Synchronet 3.21a-Linux NewsLink 1.2