Skip to main content
adding a new curious case of time standing still in the file attributes but not the exif data
Source Link
jxramos
  • 903
  • 4
  • 12
  • 21

I believe there may be a few things at play that could account for this.

1. Air Drop Failure

Just now I was in the process of moving a bunch of low priority files off my device. At some point in the evening Air Drop failed a transfer. I took a screen shot of the moment and the notification as seen here Air drop from "device" failed

When I walked backwards after noticing many minutes later that the files that were transferring did not match the dates that were expected I scrolled backwards to all those files created this evening. The first file that had the mismatching timestamp was listed just before the above screenshot in finder. That's strong evidence that something got corrupted on the iOS or macOS side at that time and the Air Drop app could no longer provide the file attribute data from the iOS device and was instead going with the macOS system time unfortunately.

File attribute time not matching content created time like other photos that were air dropped

On my macbook is some mysterious CPU surging occurring from mds and it's sibling mds_stores, each taking up 72.1% and 49.90% respectively surprisingly enough.

All photos share the same Created and Modified file system attributes and yet the embedded exif content created timestamp seems to be on a different clock that's actually moving.

Activity Monitor singling out mds process Activity Monitor singling out mds_stores process Activity Monitor

2. Bug in Photos

I was reviewing another batch of air drops I just executed now starting at a date I think came after the air drop failure experience above. I found an curious inexplicable set of timestamps where the Created and Modified times stood still for a round of photos of a single subject. Take a look at the following screen snippets from Finder for these files

Image 1

Created: Friday November 25, 2022 at 11:32 AM

Modified: Friday November 25, 2022 at 11:32 AM

Content created: Friday November 25, 2022 at 11:07 AM

1107am

Image 2

Created: Friday November 25, 2022 at 11:32 AM

Modified: Friday November 25, 2022 at 11:32 AM

Content created: Friday November 25, 2022 at 11:08 AM

1108am

Image 3

Created: Friday November 25, 2022 at 11:32 AM

Modified: Friday November 25, 2022 at 11:32 AM

Content created: Friday November 25, 2022 at 11:09 AM

1109am

I believe there may be a few things at play that could account for this.

1. Air Drop Failure

Just now I was in the process of moving a bunch of low priority files off my device. At some point in the evening Air Drop failed a transfer. I took a screen shot of the moment and the notification as seen here Air drop from "device" failed

When I walked backwards after noticing many minutes later that the files that were transferring did not match the dates that were expected I scrolled backwards to all those files created this evening. The first file that had the mismatching timestamp was listed just before the above screenshot in finder. That's strong evidence that something got corrupted on the iOS or macOS side at that time and the Air Drop app could no longer provide the file attribute data from the iOS device and was instead going with the macOS system time unfortunately.

File attribute time not matching content created time like other photos that were air dropped

On my macbook is some mysterious CPU surging occurring from mds and it's sibling mds_stores, each taking up 72.1% and 49.90% respectively surprisingly enough.

Activity Monitor singling out mds process Activity Monitor singling out mds_stores process Activity Monitor

I believe there may be a few things at play that could account for this.

1. Air Drop Failure

Just now I was in the process of moving a bunch of low priority files off my device. At some point in the evening Air Drop failed a transfer. I took a screen shot of the moment and the notification as seen here Air drop from "device" failed

When I walked backwards after noticing many minutes later that the files that were transferring did not match the dates that were expected I scrolled backwards to all those files created this evening. The first file that had the mismatching timestamp was listed just before the above screenshot in finder. That's strong evidence that something got corrupted on the iOS or macOS side at that time and the Air Drop app could no longer provide the file attribute data from the iOS device and was instead going with the macOS system time unfortunately.

File attribute time not matching content created time like other photos that were air dropped

On my macbook is some mysterious CPU surging occurring from mds and it's sibling mds_stores, each taking up 72.1% and 49.90% respectively surprisingly enough.

All photos share the same Created and Modified file system attributes and yet the embedded exif content created timestamp seems to be on a different clock that's actually moving.

Activity Monitor singling out mds process Activity Monitor singling out mds_stores process Activity Monitor

2. Bug in Photos

I was reviewing another batch of air drops I just executed now starting at a date I think came after the air drop failure experience above. I found an curious inexplicable set of timestamps where the Created and Modified times stood still for a round of photos of a single subject. Take a look at the following screen snippets from Finder for these files

Image 1

Created: Friday November 25, 2022 at 11:32 AM

Modified: Friday November 25, 2022 at 11:32 AM

Content created: Friday November 25, 2022 at 11:07 AM

1107am

Image 2

Created: Friday November 25, 2022 at 11:32 AM

Modified: Friday November 25, 2022 at 11:32 AM

Content created: Friday November 25, 2022 at 11:08 AM

1108am

Image 3

Created: Friday November 25, 2022 at 11:32 AM

Modified: Friday November 25, 2022 at 11:32 AM

Content created: Friday November 25, 2022 at 11:09 AM

1109am

connecting it to suspicious app usage on the macbook.
Source Link
jxramos
  • 903
  • 4
  • 12
  • 21

I believe there may be a few things at play that could account for this.

1. Air Drop Failure

Just now I was in the process of moving a bunch of low priority files off my device. At some point in the evening Air Drop failed a transfer. I took a screen shot of the moment and the notification as seen here Air drop from "device" failed

When I walked backwards after noticing many minutes later that the files that were transferring did not match the dates that were expected I scrolled backwards to all those files created this evening. The first file that had the mismatching timestamp was listed just before the above screenshot in finder. That's strong evidence that something got corrupted on the iOS or macOS side at that time and the Air Drop app could no longer provide the file attribute data from the iOS device and was instead going with the macOS system time unfortunately.

File attribute time not matching content created time like other photos that were air dropped

On my macbook is some mysterious CPU surging occurring from mds and it's sibling mds_stores, each taking up 72.1% and 49.90% respectively surprisingly enough.

Activity Monitor singling out mds process Activity Monitor singling out mds_stores process Activity Monitor

I believe there may be a few things at play that could account for this.

1. Air Drop Failure

Just now I was in the process of moving a bunch of low priority files off my device. At some point in the evening Air Drop failed a transfer. I took a screen shot of the moment and the notification as seen here Air drop from "device" failed

When I walked backwards after noticing many minutes later that the files that were transferring did not match the dates that were expected I scrolled backwards to all those files created this evening. The first file that had the mismatching timestamp was listed just before the above screenshot in finder. That's strong evidence that something got corrupted on the iOS or macOS side at that time and the Air Drop app could no longer provide the file attribute data from the iOS device and was instead going with the macOS system time unfortunately.

File attribute time not matching content created time like other photos that were air dropped

I believe there may be a few things at play that could account for this.

1. Air Drop Failure

Just now I was in the process of moving a bunch of low priority files off my device. At some point in the evening Air Drop failed a transfer. I took a screen shot of the moment and the notification as seen here Air drop from "device" failed

When I walked backwards after noticing many minutes later that the files that were transferring did not match the dates that were expected I scrolled backwards to all those files created this evening. The first file that had the mismatching timestamp was listed just before the above screenshot in finder. That's strong evidence that something got corrupted on the iOS or macOS side at that time and the Air Drop app could no longer provide the file attribute data from the iOS device and was instead going with the macOS system time unfortunately.

File attribute time not matching content created time like other photos that were air dropped

On my macbook is some mysterious CPU surging occurring from mds and it's sibling mds_stores, each taking up 72.1% and 49.90% respectively surprisingly enough.

Activity Monitor singling out mds process Activity Monitor singling out mds_stores process Activity Monitor

Source Link
jxramos
  • 903
  • 4
  • 12
  • 21

I believe there may be a few things at play that could account for this.

1. Air Drop Failure

Just now I was in the process of moving a bunch of low priority files off my device. At some point in the evening Air Drop failed a transfer. I took a screen shot of the moment and the notification as seen here Air drop from "device" failed

When I walked backwards after noticing many minutes later that the files that were transferring did not match the dates that were expected I scrolled backwards to all those files created this evening. The first file that had the mismatching timestamp was listed just before the above screenshot in finder. That's strong evidence that something got corrupted on the iOS or macOS side at that time and the Air Drop app could no longer provide the file attribute data from the iOS device and was instead going with the macOS system time unfortunately.

File attribute time not matching content created time like other photos that were air dropped