My old MacBook Pro running macOS 10.13.6 gives all the info I care about in the Finder when I select the file in interest, pointed out by the red rectangle. My new M1 MacBook Air running macOS 13 doesn't do the job well. I have to resize the window, so that I can see the dimensions info. How can I make my MacBook Air show the file info the same way that the older macOS does? ### Preview options. I can set preview options for a particular image, though it affects just the one I selected.

System: macOS 11.6.1, MBP 2019 16in I am having a persistent issue with certain tags. I have a tag, call it "post", that I use as a toggle. I set it on files that I need to find to upload to a certain cloud site. I set it on files that I need to attach to an email. I set it on files that I need to deliver in a presentation. After I have done the action with the files, I unset the tag. The tag resides in my sidebar as a favorite. It is colored yellow. My problem is, the tag sometimes refuses to be unset. It refuses to be unset in a rather disturbing manner. It refuses to be unset to disappear from the favorite list *but it shows no tag in the Finder list view*. Here is a view with the ghost-tagged file and a valid-tagged file. I have tried these four options: * I have toggled the post tag on and off to the file using the favorites view. While I do this, I see the xattr com.apple.FinderInfo and com.apple.metadata:_kMDItemUserTags toggle on and off (see further below). * I added the folder containing the file to the Spotlight "do not search" preference pane (Privacy) to delete the Spotlight index. The ghost-tagged file disappeared from the favorites list. I rebooted. I removed the folder from the Spotlight do not index list. The ghost-tagged file reappears. * I used various approaches with xattr to view the meta attributes and remove them with -dr. I found that I could remove all xattr characteristics. The ghost-tagged file seemed to drop from the favorites. But when I clicked to a different favorite tag and returned to the post tag ... there was the ghost-tagged file again *and it had absolutely no meta-xattr settings*. * I have deleted the post tag entirely using the Finder preferences. I then created a new tag with the same name. The ghost-tagged file reappears. * I used OnyX to remove the Spotlight index file. A slight wrinkle perhaps. I have my internal hard drive partitioned into three volumes. Some of the above disaster happens with files that are on other volumes. Another slight wrinkle perhaps. I am using DevonThink to index portions of the external volume that contain the files. I looked at the DT database for the tag. It shows no file is contained in that tag. What puzzles me primarily is what else I should be doing to purge the ghost tag definitively. Should I boot into safe mode to purge something? Should I rinse the file through some secondary app to remove the tag (the files are primarily PDFs, and I have rw access to them as seen in the Finder info box)? My reading suggests this may a problem without an answer, or the answer is fairly deeply hidden. Any thoughts would be appreciated, even if only to confirm that this mystery is just one of those hidden gems in using macOS.

I have written long ago an Applescript script that exports pictures selected in Apple Photos app with various basic options, such as adding borders, adjusting size, tuning for Web publishing, etc, and the addition of metadata copyright info using an exiftool command thru a shell script. But I cannot figure how to preserve the original files metadata in the exported images, and this turns out to become a critical need now in my current activities. I am considering locating the original file in the "Masters" Photo Library folder, extracting and saving the metadata with an exiftool command, and applying the same metadata to the exported files, but the simple task of obtaining the POSIX path of the original file proves to be challenging (I am 72 years old) and the other tasks challenging as well. Anyone here with better ideas ?

While I can edit books' author metadata in the list view, I can’t seem to be finding a way to set multiple authors for a single title. Is there any way to do this, so that I can have, let's say, two separate author entities for a book? defaults read ~/Library/Containers/com.apple.BKAgentService/Data/Documents/iBooks/Books/Books.plist --- ..., { BKAllocatedSize = 131072; BKDisplayName = "An Introduction To Software Architecture"; BKGeneratedItemId = 409BAEEB1FD9D2272D63E97BFB7CDEBD; BKGenerationCount = 3; BKInsertionDate = 558100869; BKIsLocked = 0; artistName = "David Garlan, Mary Shaw"; explicit = 0; isPreview = 0; itemName = "An Introduction To Software Architecture"; metadataMigrationVersion = 20140106; modificationDate = "2000-11-13 17:55:48 +0000"; pageCount = 42; path = "/Users/Sepehr/Library/Mobile Documents/iCloud~com~apple~iBooks/Documents/An Introduction To Software Architecture.pdf"; releaseDate = "2000-11-13 12:55:48 +0000"; sourcePath = "/Users/Sepehr/Books/An Introduction To Software Architecture.pdf"; updateDate = "2000-11-13 17:55:48 +0000"; versionNumber = 0; }, ... How can I get more than one author added in the metadata for an iBooks document?

In Catalina it is not possible to edit audiobook metadata anymore as it was possible using iTunes in previous macOS versions. I tried a third-party tag editor (kid3 ), successfully edited the audiobook metadata, but still, when I import the audiobook into the Books app, the metadata is wrong. What could possibly be going on, is there anyway I can work around this issue?

I had to reformat an external raid drive (called *Joshua*) after expanding its size. After reformatting it, I restored it from our TM drive (called *Moses*). However once everything is copied over and I go to back it up, TM wants to call the new drive *Joshua 1*, and of course take up the full space of the drive. I should mention at this point, that we are on a 2023 MacMini M2 Pro, with Sonoma 14.5. This seems to be significant because the recent versions of MacOS format a TM drive as APFS by default. For some reason, inheritbackup and associatedisk do not work with APFS, or if they do, it is not well documented. https://apple.stackexchange.com/questions/375894/inheriting-time-machine-backup-invalid-target/376133#376133 mentions a way to resolve moving time machine from one Mac to another. This case is somewhat different in that I am "merely" trying to get TM to recognize the "Old" Joshua backup as being the same as the "New" Joshua's data. As this other post suggests trying, I got the extended metadata from the respective folders so that hopefully I can write new metadata. For some reason, though if I put xattr -l /volumes/Joshua into terminal, it does not give me any metadata. Not sure if I am doing it wrong, or if Joshua simply doesn't have any metadata. I put the UUID metadata from the TM backups into a spreadsheet (I have two backups that I pulled data from; and a third backup that I am keeping offline for safety reasons.) I can't seem to bring the screenshot in, but com.apple.backupd.SnapshotVolumeUUID are identical for the old Joshua between Moses and OffsiteBackup. I thought I found what I needed; however, the com.apple.backupd.SnapshotVolumeUUID for the new Joshua are different for Moses and OffsiteBackup. My ultimate goal is to get Moses (and the other offsite backups) to associate the "new" Joshua with the backup data for the "old" Joshua. 1. I have not been able to get inheritbackup or associatedisk to work; and my research indicates that this is due to the TM drives using APFS. Is this correct? 2. Is com.apple.backupd.SnapshotVolumeUUID the "magical" metadata that I need to change to get Moses to recognize the "new" Joshua in place of the "old"? Or is there something else? And how do I get xattr to show me what the metadata for the new /Volumes/Joshua? TM will be busy restoring data for most of the weekend, but I'll be monitoring this post over the weekend. Thank you for any help you can give.

I know less about the nuances of the pdf file format than I might like, but I'm not completely ignorant either. "Resolution" might mean something when dealing with raster images (jpg, png, etc), but the pdf file format is this mixed multimedia format that is partly vector most of the time. When I have a pdf file highlighted in Finder, I might see something like this: But on what should be a very similar pdf file, I see a wildly different resolution: This isn't of purely academic interest to me. The overweight pdfs all seem to have 2160 x 2944 resolution, and the reasonably trim pdfs all seem to have 567 x 774 resolution. I have further questions in that direction but since this is a one-question-at-a-time sort of place, I am only asking what this piece of metadata is representing and whether Finder is just pulling those numbers out of its ass or otherwise making them up from nothing. Is this something like a DPI setting compared to the width and height of the media box (or crop box, or whatever the other pdf boxes are)? Is there some deeper meaning? I would be happy with as technical answer as could be provided, as that might let me formulate better followup questions in the other forum.

Some time during the transition from iTunes to Music (or perhaps another time), more than a thousand of my songs got mangled and the links from the library to the files were broken. I have my media located under /Volumes/Media/iTunes/iTunes Media/, and this is also the location set in library settings in Music; but somehow the path for these 1000+ files is under /Volumes/Media/Music/Music, even though that location has never been used, so Music complains about missing files. I am now trying to re-associate these songs using the [FixLinks](https://discussions.apple.com/docs/DOC-250002671) script. In many cases, however, it looks like something’s gone wrong when editing metadata, or perhaps I’ve manually renamed folders on disk for some reason (though I don’t know why I would) – at any rate, things like artist and album names in Music do not match the file and folder names on disk. The names on disk are **correct**, and the metadata in Music is **incorrect**. Since this is generally something that affects larger groups of songs, I wanted to batch change the relevant info in Music. What I expected to do: - Select an album / artist / group of songs - Get Info - Fix the data that need fixing - Hit OK - Run FixLinks script and correctly match library item to file on disk But no. Editing the incorrect data and hitting OK has absolutely no effect whatsoever. No metadata is changed if files are missing, but only in that one scenario where I select multiple songs with missing files: | | Single file | Multiple files | |---------------|:-----------:|:---------------:| | Files present | ✅ | ✅ | | Files missing | ✅ | ❌ | This leaves me back at editing metadata one song at a time – which is not particularly fun when there are 700 songs to edit, and I’d rather not have to. ### Is this a bug in Music? Is there some way to get around it?

I have 2 albums (CD-rips) that are fine on MacOS Music on my MacBook, but after I sync them onto my iPhone, each has a track or two that gets split into a separate album with the same name. **Again, the albums are *not* split in MacOS Music.** They only get split on iOS. Strangely, the split only happens on the *second* sync. The sync which adds the album will result in the album being intact. But on the *next* sync, the album will suddenly get split on iOS (and *only* iOS). Before you hit me with the usual solutions, please know that I tried all of the following: * I have checked and triple-checked the metadata. It's correct. The only fields that differ are "Artist" and "Track Number". * I have unchecked the "compilation" checkbox and then rechecked it and then re-synced * I have deleted the tracks from MacOS Music and re-imported them and then re-synced Here's what the album looks like in MacOS Music and then in iOS after 2 syncs: Is there any way to stop this iOS split from happening?

I often "Save Attachment…" of a PDF contained in an email that was received. I don’t know dit the PDF file after saving, so the version and link back to the email was created in the "Save Attachment…" process. Ideally, I would like to disable this feature. Alternately, I would like to know some process which can remove this linking in a scriptable or automated way that is faster than my current work-around to Print… and Save as PDF… each file. Can this metadata be easily removed or a different save attachment action be crafter do avoid the linking of a file to a specific email?

Information in my photos library seems to prevent Photos.app from effective facial recognition. Part of the reason is Photos.app's ancestor had features that did not age well---like manually selecting faces and naming them. I have a new M4 Mac Mini and want to give it a fair shot at leaving behind past sins. Exporting the photos library, migrating it over, and resetting people and pets are suggestions that do not solve the problem for me. My question solicits feedback about what seems like a good solution. Here it is: 1. Select all photos and videos in my library and export the original, unmodified files with XMP sidecar files into a single folder. 2. Programmatically remove suspect XMP tags, like Person1 in a script. 3. Open or import all the photos and videos in Photos.app on the new machine. Photos.app will incorporate information from the XMP files when constructing a new database, right? The issue is that some user-supplied information, like geographic location, does age well, even if it isn't "baked into" the exif metadata, so I would like to retain that information and remove only certain tags. Consider an XMP file exported along with an unmodified .heif file:

53.243431091308594
         W
         N
         0
         0.0
         17.57313346862793
         2010-01-04T23:41:39Z
         0.0
         2010-01-04T16:41:39-07:00
         
            
               Person Name 1
               Person Name 2
               Person Name 3
            
         
         2024-05-30T18:07:47-06:00

I would need to remove the block:

Person Name 1
               Person Name 2
               Person Name 3

And any other desired tags. Is this OK, and then import all these photo and video files into Photos.app on the new machine and let it get to work? Or perhaps even add new tags to search for "scrubbed" files once in Photos.app? Maybe this workflow is what PowerPhotos and GraphicConverter also do?

gstat can show several timestamps with **nanosecond precision**, including: - **Access time (atime)** - **Modify time (mtime)** - **Change time (ctime)** - **Birth time (btime)** Example output:

$ gstat /path/to/file
Access: 2025-01-14 08:25:18.137794004 +0100
Modify: 2025-01-14 08:25:18.120619368 +0100
Change: 2025-01-14 08:25:18.120619368 +0100
Birth:  2009-11-26 12:57:46.000000000 +0100

However, **Date Added is not included in gstat’s output.** Finder is able to sort files by **Date Added** even when multiple files are created within the same second, meaning macOS must store this attribute with sub-second precision. But I haven’t found a way to retrieve it. So far, the only ways I’ve found to get **Date Added** are: - **Finder list view** → Displays **minute-level precision** (e.g., *Dec 27, 2023 at 4:06 AM*). - **mdls** → Shows kMDItemDateAdded, but only with **second-level precision**:

$ mdls -name kMDItemDateAdded /path/to/file
  kMDItemDateAdded = 2023-12-27 09:06:44 +0000

How would I obtain the "Date Added" attribute for a file with nanosecond precision?

Is there any way to get *all* of the metadata associated with a file in Terminal? By "metadata" I mean things metadata and properties that are not stored in nor derived from the file's contents (i.e., checksum, UTD, image resolution, etc.), but rather reside in the filesystem's data about the file (i.e., last time changed, inode, permissions, extended attributes, etc.).

On photos and videos I paste the descriptions and links in the Caption field in the iPhone Photos app. Videos that I then send from my iPhone to my MacBook using Airdrop retain this captioned information which is visible in a “Description” field in the finder Get Info on the file. For still images such as PNG and JPG this captioned information which information is lost. I want to preserve these comments. The setting to preserve comments before sending the files is ignored. iCloud does retain this caption information, as I can view this caption in the web browser when logged into iCloud. Downloading the images does not preserve the comments. Is there a third party app or other process that will preset this caption metadata stored I can archive media?

I have downloaded an .mkv files from Safari. When I open "Info" in Finder on the file, I see the following link to where it was downloaded from: How can I remove that metadata from the file?

I took over two thousand pictures while on vacation in Europe with my partner's iPhone 15 Pro. Going through them now, I see that the timestamps (as stored in the 'EXIF' metadata section of the image) on hundreds of them are completely wrong - they are off by exactly 9 hours, which happens to be the time zone difference between my home in California and the photo location in Europe. Examples (these pictures were all taken in the same general location at roughly the same time and are clearly sequential): - IMG_2011 - EXIF timestamp 02:19:45 (I was asleep at 02:19 local time, so this is obviously wrong) - IMG_2012 - EXIF timestamp 11:25:39 (this is the correct local time) - IMG_2013 - EXIF timestamp 02:25:58 (taken 19 seconds after the previous image but with wrong timestamp) - IMG_2014 - EXIF timestamp 11:28:09 (taken ~2 minutes after the previous image) with correct timestamp All three EXIF timestamps are equally wrong, on the 'bad' images - DateTime, DateTimeOriginal, and DateTimeDigitized. Of particular interest are images IMG_2012 and IMG_2013 - they were taken from the same spot, just 19 seconds apart, but show timestamps 9 hours apart. The GPS location of all the photos is correct - so it's not as if there was no GPS signal at some points in time causing the camera to think it was back in CA. These are outdoor photos so again, no GPS issues. The EXIF timestamps are very important to me for various reasons so this is a big issue. I do have EXIF tools to correct the timestamps, but it is a terribly tedious procedure. I did closely analyze the full EXIF data, and I did notice one thing - for the images with 'correct' timestamps, they show OffsetTime, OffsetTimeOriginal and OffsetTimeDigital as +2:00; and for the images with the wrong timestamps, they show OffsetTime, OffsetTimeOriginal and OffsetTimeDigital as -7:00. I'm guessing these are relative to GMT/UTC, as Spain is currently UTC+2 and California is UTC-7. So something is causing the iPhone to mark half the images with the wrong offset for some reason. Here's a composite screenshot of the two images discussed above (screenshots from the iPhone) that were taken 19 seconds apart. As you can see, the image on the left is showing 11:25am, while the image on the right is showing 2:25am - 9 hours off. Interestingly, they sort correctly on the iPhone despite the time issues. And here's a snapshot of the EXIF data for the above two images: and a snapshot of the GPS data portion of the EXIF data: The "GPSTimeStamp" entry - approx. 9:25 - is the correct 'UTC' time for both pictures. I'm curious to understand how this could have happened, but I guess I also need to find a way to correct the 'bad' versions. Minor update - the first ~1,600 photos on the trip (taken over a 2 week period) have accurate metadata. The first 'bad' timestamp was IMG_1800, taken Sep-20-2024, and was part of a sequence of images taken inside a church in Montserrat - no obvious difference from previous image. For the remainder of the vacation (2 days, approx 200 images), the image metadata was 'mostly bad' with occasional 'good' metadata, but a few sequences of 'mostly good' metadata with occasional 'bad' metadata. The oddest thing is that the 'good' and 'bad' images were often taken in the same location / similar time, which rules out environmental / positional issues. Now that we are back in the US, I have very few new pictures to analyze and the everything appears to be back to normal (but we won't know until we next travel). UPDATE - here's a snapshot of a windows file manager window, showing the 'date taken' information for a sequence of images taken throughout the day (I realize windows file manager isn't always the most reliable indicator but in this case I can confirm the 'date taken' column corresponds to the exif data in the files). The images shown are in chronological sequence. Img_1914 and 1915 have timestamps circa 3am (I was sleeping at that time). Img_1916 has a timestamp 12:24pm and is correct. Then img_1917 goes back to circa 3am, and the images all the way to img_1931 are too early by 9 hours. Then img_1932 has the correct time of 3:15pm, then the images after that are bad again, until img_1939, which shows the correct time of 7:44pm. The images then stay 'good' until Img_1951, which jumps back 9 hours. The 'good' and 'bad' images were in many cases taken in the exact same location, and ALL images have the correct GPS time.

**First, some background:** For those of you who edit photos using Apple software, you may have encountered *AAE sidecar* files, which are generated automatically by the Photos app (for iOS or macOS) when you export an edited image. These sidecars contain the data representing the edits made to the original image, such as crops or recoloring. Following an export, these AAE sidecar files will usually be located in the same directory as the original, exported image/JPEG file. Theoretically, edits made to an image using the Photos app (on iOS or macOS) are "non-destructive," meaning that you can always revert to the original image anytime after editing. **Now, the problem:** For the life of me, I cannot understand if these AAE files are actually good for anything once they exist. If you try to import an original image file and its AAE into the Photos app, you only see the original image. The edits don't seem to transfer. Likewise, advice from Apple and user forums regarding the transfer of edited photos suggest that you use iMessage, AirDrop, or other methods to copy the *edited* image itself to the new destination. This process, however, defeats the idea of non-destructive edits since it will prevent you from ever reverting to the *original* image. **Finally, the question:** Does the AAE sidecar file serve any purpose? If so, what does it actually offer a user or program once it exists? Can we *do* anything with it?

Can’t find answer to this anywhere! Using the shortcuts app, is there a way to automate the process of taking metadata (or at least location, date, time) from a photo/video and pasting it into another photo/video? This shortcut gets half way there.. https://www.icloud.com/shortcuts/4a1e6dc3c73645618e72b7bf67127050 Any help appreciated thanks! iOS 17.5.1, iPhone SE 2020

Business user here. I didn’t get an answer at discussions@apple so now I am here. I use iCloud for my law office, every client folder has its own Numbers file so it’s at least hundreds of .numbers files that are affected and interfere with my daily work in a devastating way. Problem is there since some months, another new problem since some 1-4 weeks. Only .numbers files that are on iCloud AND shared to other people (everyone with link / read only) are affected. it is independent of MacOS and device, I have quite a lot of Mac Minis and Macbooks. This is what happens to -all- of the above mentioned .numbers files: Their contents are not searchable anymore. This is horrible for me, I rely on numbers values and formulas that give out certain strings that need to be findable with finder or spotlight search. They get only searchable again if I copy the single .numbers file to a non shared place on iCloud AND open, edit anything and save and close them. Only workaround which is horrible for my office. Alternatively ".nosync" in filename helps too. Since some weeks: When opening the .numbers files (which is saved on the ssd, so no cloud download necessary) a loading bar of numbers app appears, which takes 10-40 seconds to open one single .numbers file. This destroys my whole workflow. interestingly when going offline and opening the numbers files it opens as usual in miliseconds although this "numbers is offline" pop-up appears. Problems disappear as soon as I deactivate file sharing and edit & save the numbers files once. So it is reproducible. Sidenote: Other shared files are not affected and are searchable. I don't use .pages files though. Problem persisted even after changing the MacBook. For general info, I use a MacBook Pro 2023 M3 Pro chip. Latest macOS and .numbers updates.

The Finder in Mac OS X 10.7 Lion shows a new piece of file metadata, "Date Added," which tracks the date an item was added to a folder. After upgrading to 10.7, none of the items in my ~/Downloads folder have "Date Added" values. I'd like to set all the empty "Date Added" values to match the "Date Modified" values, but I can't figure out how to set the "Date Added" attribute to a specific value. My first guess was this: xattr -w com.apple.metadata:kMDItemDateAdded "2012-02-19 16:34:47 +0000" myfile But that doesn't seem to work (though it doesn't report an error either).