I had some files on an old thumb-drive, and recently I was going through and discovered that all/most of the files were no longer readable by any of my macs. I seam to remember having similar problems like this while back, and finding an apparent link to my choice of format, so I ran diskutil list in terminal: /dev/disk3 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *134.2 GB disk3 1: EFI EFI 209.7 MB disk3s1 2: Apple_HFS my-old-files 133.9 GB disk3s2 And I tried ls -l total 3858320 -rw-r--r--@ 1 kipbits staff 3430100 Nov 21 2016 2015-12-24.pdf drwxr-xr-x 8 kipbits staff 272 Sep 26 2016 2016-sep-14-files -rw-r--r-- 1 kipbits staff 25642888 May 18 2015 myold.mp4 -rw-r--r--@ 1 kipbits staff 884 Jul 31 20:20 someold.txt -rw-r--r--@ 1 kipbits staff 1320157184 Sep 21 2016 someold.iso drwxr-xr-x 4 kipbits staff 136 Sep 27 16:23 anotherdir -rw-r--r--@ 1 kipbits staff 626214959 Nov 5 2016 someold.mp4 drwxr-xr-x 14 kipbits staff 476 Nov 2 2016 sept2016files I think this looks normal? The problem is, I'm not able to open any of my files. I get the following errors: pdf: **The file “some-old.pdf” could not be opened.** It may be damaged or use a file format that Preview doesn’t recognize. txt: 800 byte files are blank rtf: **The document “some-old.rtf” could not be opened.** mp4: **QuickTime Player can't open "some-old.mp4".** To see if additional software is available that will enable QuickTime Player to open the movie, click Tell Me More. dmg, iso: will mount but did not test further pkg: **The operation couldn’t be completed. (com.apple.installer.pagecontroller error -1.)** Couldn't open "some-old.pkg" I found a thread on apple saying "*The partition map type doesn't really make any difference for non bootable volumes*", although i don't get any of these problems when using Master Boot Record & ExFAT. None of the files are more than a couple years old, so i don't think there should be any compatibility issues, and none of the files were corrupted when I copied them to the drive. I have had this same problem with other drives, and they were perfectly usable after reformatting, although this involved erasing files. My question is: **Is there a way to recover my files?** The file-sizes still display that the files are there. Is there a way to save these files and make them readable? ...Also, if it makes any difference, I am using El Capitan(for dev purposes) > **Update------------------------------------------------------------------------------------------------(04/Oct/2017)** I did a hexdump for some of the files in question. my output was something like this: 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000370 00 00 00 00 0000374 what does this mean? do you think a recovery app could even help me here? here are some threads that are perhaps related: ...Also could this possibly be related to SIP? I first noticed this problem around when i first upgraded to El Capitan. Or perhaps there is something else going on? I have recently been experimenting with windows and various forms of linux, and have been moving files around with thumb drives. Perhaps I plugged one in to the wrong computer and corrupted all the files? Whatever the cause, I'm wondering if the files might still be recoverable? Is hexdump a good way to diagnose recoverability? **Would buying a recover app just be a waste of $100?**

I have an old harddisk that's formatted as HFS, which I would like to read on my modern Mac that runs Ventura. I've got the physical connection covered: I've connected the HD via a SATA/PATA to USB bridge to my Mac. The next step is to read the filesystem. I've installed macFUSE and fuseHFS. But neither of those software packages comes with ANY documentation. How do I get this disk to show up in the Finder?

During the lockdown I decided to use some of my time to backup all the all Mac disks and floppies I have at home so I can store them in a somewhat more readable format that SyQuest cartridges and MFS formatted SD 400k floppies and finally free up lots of space in some libraries. Doing so I eventually discovered that macOS Catalina can neither mount HFS "non plus" (Apple removed HFS standard support in 10.15, apparently just for the sake of it... Hating this approach to "old", even more when they're keeping support for FAT12 DOS floppies and removing support for their own floppies...) nor MFS (it's actually not supported since Mac OS 8, but from Mac OS X 10.4 Apple offered sources to build a MFS read only support using the great system expandability features that OS X inherited from NeXT). So, after the still ongoing struggle to get data off damaged floppies (I started weeks ago and still probably have a couple of weeks to go) I'm wondering how to easily access that data from disk images. I know I can use emulators such as minivmac, Sheepshaver and Mojave on VirtualBox to access that data, but that would mean a lot more work to get readable data. I'd love to simply be able to mount old disks and access data through finder. **Chapter 1: HFS Standard** - HFS standard options are still in /System/Library/Filesystems/**hfs.fs** plists, so I'm wondering if Apple disabled old HFS support through some external option. Does anyone know if there's any option to enable it back? (Maybe something like boot-args="no32exec=0" to run 32-bit code). Does anyone know what would happen if I took hfs.fs from Mojave and used it in Catalina? Would it possibly work? - **thejoelpatrol/fusehfs GitHub repo** -> managed to build it botching the code but when I mount Standard HFS images I get errors such as Device not configured - **0x09/hfsfuse GitHub repo** -> it builds and installs correctly, but when I try to mount old HFS images I get Plain HFS volumes not currently supported. Couldn't open volume: Undefined error: 0 - **hfsutils** (https://www.mars.org/home/rob/proj/hfs/) -> these are the only working ones but they're a mess to work with. FuseHFS is apparently working with it, but surprisingly it doesn't seem to work - **elliotnunn/machfs GitHub repo** -> I was suggested this library, it seems a great idea, but using DumpHFS seems like using hfsutils **Chapter 2: MFS** - **MFSLives** https://web.archive.org/web/20080517055506/https://developer.apple.com/samplecode/MFSLives/index.html -> this was the sample code that apple distributed from Tiger onwards. I read it was supported even on 10.8. Unfortunately it's built for 32 bit so Catalina can't use it (*why do they keep removing features?*) and I can't get it to build in Xcode. - **d235j/fusemfs GitHub repo** -> I can't find a way to build it either, even after updating the project, updating the code from linked repositories to the last version. Even if libfuse_ino64.2.dylib is in /usr/local/lib and that path is added to Xcode options I just keep getting ld: library not found for -lfuse_ino64.2 Unfortunately I'm too much of a noob to be able to edit those projects, but I think it would be great if Apple offered to its user the chance to read their old Mac data like we're able to do with old DOS disks. **Possible solution?** Apparently FuseMFS is using zydeco/libmfs GitHub repo (which is used in zydeco/minivmac4ios GitHub repo together with [libhfs](https://github.com/zydeco/minivmac4ios/tree/master/libhfs)) to create a FUSE wrap to access those file systems, would it be easier to update FuseMFS making it buildable on Catalina and add there libhfs? I'm just wondering it, but not being a developer I really don't know if it's feasible. Thanks in advance :)

After upgrading to Sonoma I've been running out of disk space (and application memory) even tho Finder shows 300+GB free. I read about it being a common problem with too much Time Machine snapshots in the disk, but I deleted it all and still didn't free almost any space. In fact, even after recreating the snapshot the size DiskUtility shows is still not very big to explain the 300gb vanishing gigs (see img below). ## Finder ## DiskUtility Some other facts (with unclear to me at present math): * DiskUtility shows only 25GB free, while Finder shows 300GB * Finder shows my Home folder with 960GB * OTOH du -h . at home dir gives 621GB * I have a 1TB SSD on a M1 Mac Mini * I'm sure DiskUtility is the right one because i'm having low space warnings often * it seems that deleting the snapshot doesn't fully show in neither totals * Grand Perspective shows 902GB used * In DiskUtility I can see a "purgeable space" that kind of matches the "black matter" I'm looking for (see above) * diskutil apfs list output (warning: I removed 100GB+ icloud files after posting some screen shots so I could work, free increased but "purgeable" is still the same, still ~300GB difference between DiskUtility and Finder free space):

APFS Containers (4 found)
|
+-- Container disk3 DFC7C2F9-82AF-4D43-BE11-1B7B963CAC69
|   ====================================================
|   APFS Container Reference:     disk3
|   Size (Capacity Ceiling):      994662584320 B (994.7 GB)
|   Capacity In Use By Volumes:   856211038208 B (856.2 GB) (86.1% used)
|   Capacity Not Allocated:       138451546112 B (138.5 GB) (13.9% free)
|   |
|   +- Volume disk3s1 E09E7634-90F6-424A-AEE0-2B47E205DB98
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk3s1 (System)
|   |   Name:                      Macintosh HD (Case-insensitive)
|   |   Mount Point:               Not Mounted
|   |   Capacity Consumed:         10122260480 B (10.1 GB)
|   |   Sealed:                    Yes
|   |   FileVault:                 Yes (Unlocked)
|   |   Encrypted:                 No
|   |   |
|   |   Snapshot:                  AADC1822-4545-48C8-82FA-0C198CB4881B
|   |   Snapshot Disk:             disk3s1s1
|   |   Snapshot Mount Point:      /
|   |   Snapshot Sealed:           Yes
|   |
|   +-> Volume disk3s2 AAC21E83-E0F5-462F-8C8B-931D11104B23
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk3s2 (Preboot)
|   |   Name:                      Preboot (Case-insensitive)
|   |   Mount Point:               /System/Volumes/Preboot
|   |   Capacity Consumed:         6054576128 B (6.1 GB)
|   |   Sealed:                    No
|   |   FileVault:                 No
|   |
|   +-> Volume disk3s3 6225A76B-5840-489C-AB82-A9200364D387
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk3s3 (Recovery)
|   |   Name:                      Recovery (Case-insensitive)
|   |   Mount Point:               Not Mounted
|   |   Capacity Consumed:         907165696 B (907.2 MB)
|   |   Sealed:                    No
|   |   FileVault:                 No
|   |
|   +-> Volume disk3s5 F8E3078B-F197-43C2-92E1-7E2D571BEEC3
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk3s5 (Data)
|   |   Name:                      Data (Case-insensitive)
|   |   Mount Point:               /System/Volumes/Data
|   |   Capacity Consumed:         836679122944 B (836.7 GB)
|   |   Sealed:                    No
|   |   FileVault:                 Yes (Unlocked)
|   |
|   +-> Volume disk3s6 C08EE347-7A71-49BB-B4EB-95817CECE5BB
|       ---------------------------------------------------
|       APFS Volume Disk (Role):   disk3s6 (VM)
|       Name:                      VM (Case-insensitive)
|       Mount Point:               /System/Volumes/VM
|       Capacity Consumed:         2148384768 B (2.1 GB)
|       Sealed:                    No
|       FileVault:                 No

Another weirdness: iCloud Drive in Finder changes to "Mobile Documents" with the warning "iCloud is not syncing. There are pending items to sync." This behavior was observed after Sonoma (3 or 4 days ago). So, what am I missing here? PS: the suggested DaisyDisk work really well, it showed the following to me: There were some purgeable stuff which were not snapshots and I could use DaisyDisk to remove it. Weird is how MacOS's didn't purge it automatically when getting the "high tide" alarm.

I am trying to get AppleScript to open a file located at iCloud Drive:Documents:Manuals:BBEdit_13.0.1_User_Manual.pdf.

tell application "Finder"
	open file "/Users/cb/Library/Mobile Documents/com~apple~CloudDocs/Documents/Manuals/Computer/BBEdit_13.0.1_User_Manual.pdf.icloud"
end tell

I obtained the filepath by right clocking the target file + option key & selecting copy... as filename. Running the script results in error

Finder got an error: Can’t get file \"/Users/cb/Library/Mobile Documents/com~apple~CloudDocs/Documents/Manuals/Computer/BBEdit_13.0.1_User_Manual.pdf\"." number -1728 from file "/Users/cb/Library/Mobile Documents/com~apple~CloudDocs/Documents/Manuals/Computer/BBEdit_13.0.1_User_Manual.pdf"

What am I doing wrong? Does anyone know what AppleScript error -1728 means?

I've been using Time Machine to backup to an external hard drive. Recently I got an error saying that TM could no longer back up to the backup volume, because it was read-only. (I assume it's read-only because something happened to the filesystem. Rebooting didn't fix the fact that the backup volume is read-only.) The error message said I should back up those TM backups, but it didn't have any link or hint about how to do so. (I can't find a way to recover the error message for any more details.) So I've got another external hard drive, of the same size, to copy the TM backups to. Various guides online say to copy the Backups.backupdb folder from the old drive to the new drive. Sounds simple enough. But when I try to do so: - Dragging the folder in Finder, or using Copy and Paste, results in the error message "The volume is the wrong format for a backup." - I didn't ask for a backup at this point; I'm just copying files. But maybe macOS is trying to be extra-helpful here and help detect and prevent a future problem. Too bad it doesn't tell me what formats are acceptable or unacceptable. - The destination volume is APFS, which is the only format that Disk Utility currently offers for creating volumes. - The old backup volume is HFS. Surely it's not a problem to copy files from HFS to APFS? Is it a problem to migrate backups from HFS to APFS? If so, how am I supposed to migrate my TM backup using a recent version of macOS? - Is there **a way to create an HFS volume** on my destination drive, in Ventura 13.4? Again, the only format options offered by Disk Utility are variants of APFS. - Given that HFS is old and HFS+ has been standard for a long time, someone could reasonably ask whether my source drive is actually HFS+. All I can say is that diskutil reports Apple_HFS, Disk Utility says "HFS Case-sensitive Not Journaled", and mount calls it hfs. Whether these labels are inclusive of HFS+, I don't know. - Surely "The volume is the wrong format for a backup" isn't referring to the old TM backup volume -- TM has been backing up to it fine until a couple of days ago. - However ... I did update the OS to Ventura 13.4 a couple of days ago. Is it possible that this update dropped TM support for HFS, and didn't provide a warning or a migration path? I'm not sure which came first, the update or the "backup volume is read-only" problem. - In case anybody asks about turning off "Ignore ownership" on this volume, which is something you're supposed to do before copying the backup to a new drive: The Finder "Get info" dialog doesn't have a checkbox for this for the destination drive (and no indication of why not). I worked around this using sudo diskutil enableOwnership disk5s2, which is the destination volume. It responded File system user/group ownership enabled, so that was apparently successful, but it still won't let me copy the Backup.backupdb folder to that volume. - In case it helps, I'm running Disk Utility's "First Aid" process on the old backup drive. No errors reported yet, still checking catalog file. - There are conflicting rumors that it is impossible , or possible , to continue TM backups from an HFS volume to an APFS volume. Can anyone confirm whether this alleged FS type incompatibility is the cause of my being able to copy backup files from one drive to another?

Just finished a copy of an external drive (exFAT) to another drive (HFS) using standard the Finder's Cmd+C, as I want to format the first drive (exFAT) to HFS. Now, I've been trying to verify all the copied files using -diff and -rsync for several hours, but for some reason, Finder has printed a "._" on all of the files on the exFAT drive, but excluded that on the destination drive. So naturally, both commands will tell me that all files differ, when they're actually the same in every other aspect. So, is there a way, maybe a certain flag or something, that lets me use either the diff command or dry rsync command to display any differences **apart** from that "._" added to the file names. For instance, I used md5 on two files, and their checksum's identical, even though their names differ.

2016 macbook.. power to question mark… it can’t find an os. Boot to recovery mode, open disk Utility Finds only os core partition with is formatted in hfs. Apple file system partition is missing. Ok so we can probably rule out the cable with is a common problem. The hard drive is there it just can’t see the main apple file system partition. Apple documentation not helpful for this case. Google shows this is a fairly common problem Try to boot. Won’t accept password. I’m certain of the password. Apple keeps os core on read only hfs partition. Password isn’t read only and can be changed while running so this must be kept on apple file system partition. Any ideas. The storage device is there and in fact the machine is reading from it. How to make machine also read from apple file system partition. It’s time to upgrade but I was hoping to hope out for m1 large MacBooks.

There are some programs that require a case-sensitive filesystem, and others that require case-insensitive. Even though Apple warns against using case sensitive file systems , in some situations it is useful. **What programs have trouble with Case Sensitive (HFSX) systems?** **What are the work-arounds?** In general, the problem is that the developers have a file in their app called FOO, but try to access the file by the name foo. In an HFS+ system that is case preserving but case insensitive, searching for foo will find FOO. That is not the case in HFSX. The general solution is therefore to 1. Find the misnamed file or folder 2. Make a copy, a link, or rename so the expected name is found

I have a MacBook with a 120 GB SSD. I bought a new one with 240 GB. I cloned the content from the old one over with an ICY BOX cloning device. I inserted new SSD in the MacBook and everything is fine and works. But I then noticed in the disk utility that the size of the partition is still the old one (120 GB). So here is what I have tried so far: 1. I dragged the partition in the pie chart to use all unlocated available space. But then I get the error from MediaKit: "Error: -5341: MediaKit reports partition (map) too small". 2. I ran GParted on a USB flash drive, mounted it and gparted noticed some errors with the partition. it immediatly repaired it. Then I tried to increase the partition within GParted. But this was not possible. GParted can't increase HFS+ format. But after repairing it with GParted, disk utility does not show free space any longer. 3. I ran Terminal and diskutil resizeVolume. But it breaks up with an error message: "Error obtaining partition map size information" And now I am completely lost. What’s wrong and what can I do to reclaim the additional space?

I have a late 27" imac with a 3TB internal drive. It currently is divided into three partitions.. one is running catalina, the second is a carbon copy of the first - the third is my music library. I would like to revert back to the system before catalina - I just don't like it. I understand that the partition holding the main startup system has been changed from HFS+ to something else , kinda dividing it into two. I have plenty of external space, including the previous last-saved setup. My questions are as follows... Can I simply reformat the main partition into the previous setup and carbon copy my old saved setup.. and then use the Carbon Copy backup of the catalina system to boot from, ikn order to update prefs etc?? Do I need to reformat both partitions - or do I need to copy my music partition and just reformat the entire interior hard drive? I AM franticly backing everything up as I go... but just need a little guidance on the "AFS to HFS+ thing...

I've been having troubles with my external HDD and have been looking so hard for a solution. I've tried everything. Diskutil, FSCK, testdisk. But only to find what I already know... "Invalid B-tree node size". It's unbelievable that Apple hasn't included a fixer for this kind of problem within its tools like diskutil. My concern is, what is the meaning of this error? Is there any solution to this problem without using a expensive 3rd party software? Isn't there any open source software to recover my data? Has anyone fixed this problem before? I certainly would love just to buy a specialized software like DiskWarrior, but I can't afford that price.

I have a 2017 MacBook Pro 15". I recently removed a windows partition. Now the disk utility is showing an HFS+ volume with 0 bytes of storage. I tried to remove it using disk utility, recovery mode, terminal and by booting into safe mode. But nothing has resolved the issue.

I have an external 2 TB Harddisk that had a 1.5 TB exFAT Partition and a 500GB HFS+ encrypted Partition. I wanted to shrink the 1.5 TB to 1 TB. I used https://www.diskgenius.com/ to shrink the exFAT Partition which worked, I ended up with a 1 TB Partition visible in Windows. But after attaching the external harddisk to Mac now the 500 GB encrypted Partition is not recognized anymore. Mac's disk utility still shows disk2s2 with 512 GB but is not able to mount it. My guess is that this disk was GPT before but got overwritten with a MBR by disk genius and that there is now data missing for MacOS to recognize the disk. Is that possible? 1. Is there any hope of recovering my data? Does HFS store some information needed for encryption in the GPT that might have been overwritten now? 2. Can I somehow force MacOS to mount disk2s2 as an encrypted HFS+ volume? 3. Does the GPT automatically get overwritten by MBR or is it possible that the MBR somehow just takes priority over the GPT and if the MBR gets deleted the GPT takes over again? Sorry if this is a dumb idea, I don't know much how these partitioning tables are stored on disk. Any help appreciated.

After some issues with my internal disk, I moved my OS on an external drive which is split into : - (disk2s2) Macintosh HD (Apple_HFS): my operating system; - (disk2s5) Volume 1 (Apple_HFS): My data Storage - Free Space: A free space partition resulting in my messing up I want to give the free space (550 GB) to Volume 1 (my data storage) but the command "resizeVolume" only allows me to give the free space to "Machintosh HD" (my OS) and not to "Volume1". The issue is that since my partitions are in Apple_HFS formats and not in APFS format, I cannot use the "resizeContainer" command as suggested in other posts. I don't want to lose any data on both partitions. How should I do it?

I know a Mac volume can be renamed... obviously. But if you look at the output of diskutil you will see that a volume also has a "device name" that corresponds to the name it was given when it was formatted: diskutil info /dev/disk0s1 | grep 'Media Name' Running it on your root volume you will probably get "Macintosh HD" (or else something like "Untitled 1" if that's how you left it when formatting in Disk Utility). It seems this doesn't change when you rename the volume after the fact. Why do these different names for the same volume exist? Does anything even refer to this hidden name? Can it be changed?

So, I wanted to do a fresh install of Catalina, and have done a backup on my USB drive. Before transferring the data to USB, I've formatted it as "Mac OS Extended (Journaled)". After I've installed Catalina, I can no longer read the data from USB, and receive message: "The disk you inserted was not readable by this computer". I've tried to read it on my Windows machine using a free program (HFSExplorer), but it couldn't even find my USB drive. I've tried to read it on Linux (Ubuntu), installed "hfsprogs", but couldn't mount it. I've also tried using several free data recovery programs, but they've managed to recover only data from my previous Linux pen drive installation that I've removed before doing a backup.

I've got Windows 7 running on my computer and I would like to partition my D: volume, make it HFS+ but I cannot find any tool that will accomplish this. Anyone had done this before? Is it possible? I have EaseUS partition tool but it does not support HFS/HFS+.

I have a Seagate Backup Plus Mac drive that, as the name implies, came with the HFS format for Mac. I reformatted it to NTFS to be compatible with a Windows PC (I was not working with Mac at the time). I tried recently to read the disk on a Mac, but unlike other NTFS disks (which can be read, albeit don't written), it don't mount at all. I also tested at other computers and my results are: - At some Linux version, it read fine out of the box - At a Windows PC it don't read by default, but it reads when I install a HFS driver (despite the drive itself still being recognized as NTFS when is mounted) Is there any way it can be read on Mac as it is, or even, reformat the disk erasing its data so it can be HFS again?

**Backstory:** After I went to the Apple Store today, the drive in my Mac was wiped by an employee as I was supposed to have it replaced. The replacement unit had an issue though, so they gave me my old machine back with the SSD already reset to factory. As the employee probably just used the DiskUtil UI to wipe the drive, I was wondering if there was any way for me to get my data back by rebuilding the HFS volume tables back to their previous state for instance. Using a backup would take days to get everything back and I want to try the other options before restoring a backup that would corrupt the data and prevent any further recovery. Small issue: I only have a Sierra Recovery USB stick, so I can only use the terminal with whatever is already installed, like gpt, diskutil or pdisk. TestDisk for instance doesn’t work as it seems like it’s lacking some dependencies in this recovery environment.