All Posts by Date or last 15, 30, 90 or 180 days.
also by Lloyd: diglloyd.com photography and WindInMyFace.com

Thank you for buying via links and ads on this site,
which earn me advertising fees or commissions.
As an Amazon Associate I earn from qualifying purchases.

Other World Computing...
B&H Photo...
Amazon
As an Amazon Associate I earn from qualifying purchases.
Upgrade the memory of your 2020 iMac up to 128GB
877-865-7002
Today’s Deal Zone Items... Handpicked deals...
$2998 $2898
SAVE $100

$3049 $2399
SAVE $650

$3508 $2998
SAVE $510

$998 $848
SAVE $150

$3999 $2998
SAVE $1001

$2299 $2299
SAVE $click

$1597 $1297
SAVE $300

$80 $33
SAVE $46

$2299 $2299
SAVE $click

$1898 $1498
SAVE $400

$2799 $2799
SAVE $click

$2299 $2299
SAVE $click

$600 $400
SAVE $200

$240 $175
SAVE $65

$699 $499
SAVE $200

$270 $270
SAVE $click

$1599 $1398
SAVE $201

$2027 $1397
SAVE $630

$1699 $999
SAVE $700

$180 $100
SAVE $80

$1199 $1099
SAVE $100

$1199 $1099
SAVE $100

$999 $949
SAVE $50

$270 $270
SAVE $click

$1699 $999
SAVE $700

OWC Thunderblade Thunderbolt 3 SSD

Blazing fast, up to 16TB.

YEE HAH!



√ No more slow and noisy hard drives!

Copying Files in macOS Can Truncate File Date/Time to One-Second Granularity

A user of IntegrityChecker reported that verification of backups was resulting in claims of changed file dates. Investigating, I found that copying files from an APFS file system to macOS Extended changes the file dates by truncating the time to the second (truncating, not rounding).

Since macOS Extended supports file times to the millisecond, there is no good explanation for this behavior other than yet one more macOS bug.

It’s a hassle to have files reported with changed dates when verifying data, so I’m making a few changes to IntegrityChecker java version (icj) to handle this situation better, such as not flagging a date change if the new date has a zero millisecond component.

Example of whacked file dates

I used the dgl finfo command to print out this information. It uses 'Carbon' APIs.

This example from one file for brevity; it happens for all files I tested (thousands).

Original on APFS volume

DataFork:         53529, 57344, closed
CreationDate      2019-05-20 22:19:19.80359873 0.3641260759.57184
ContentModDate    2019-05-20 22:19:19.80359877 0.3641260759.57444

Copy on another APFS volume

DataFork:         53529, 57344, closed
CreationDate      2019-05-20 22:19:19.80359873 0.3641260759.57184
ContentModDate    2019-05-20 22:19:19.80359877 0.3641260759.57444

Copy on macOS Extended volume

DataFork:         53529, 57344, closed
CreationDate      2019-05-20 22:19:19.80359000 0.3641260759.0  <== millis truncated
ContentModDate    2019-05-20 22:19:19.80359000 0.3641260759.0

Simon N writes:

Are you sure HFS+ supports milliseconds? As far as I know, the date resolution on HFS+ is 1s, so it seems to be inevitable that the milliseconds from APFS-originating files get cut off. One might argue Apple could have implemented rounding instead of truncating, but the outcome would (essentially) be the same.

MPG: I see that Wikipedia shows "Date resolution" as "1s", so perhaps my assumptions are invalid.

Because macOS Extended (HFS Plus) uses a 48 bit number for date/time (16 bit each for High/Low/Fraction), I had assumed that non-zero values in the fraction part of the number were milliseconds.

Since many files have non-zero values in the fraction part, it only made sense that this represents milliseconds. But if the file system only does time to the second, then these values are essentially garbage, or being used for oddball purposes by Apple.

Still, rumors suggest that macOS S***ForBrains 99.99.99 will fix all bugs forever.

OWC Accelsior 4M2 PCIe SSD
6000 MB/sec!
Mac or PC.


Ideal for Lightroom, Photoshop, video.
Capacity up to 16TB!

Save the tax, we pay you back, instantly!

diglloyd.com | Terms of Use | PRIVACY POLICY
Contact | About Lloyd Chambers | Consulting | Photo Tours
Mailing Lists | RSS Feeds | Twitter
Copyright © 2020 diglloyd Inc, all rights reserved.
Display info: __RETINA_INFO_STATUS__