What we are building We maintain an append-only on-disk store. Every update has the same shape: write a temporary file and make its contents durable; rename() it to its final name; only then publish the new state to the rest of the system. Step 3 is the one we must get right. Once we publish, other components treat the preceding step as committed. If power is lost after we publish but the renamed entry was not yet durable, we would have published a state the filesystem can no longer support after reboot. Our question is therefore narrow: after rename() returns, what does Apple document about when the resulting directory entry may be treated as durable across power loss? Two cases matter, and we would like them distinguished wherever the answer differs: the target name did not exist before — an entry is added; the target name already existed and is replaced — an entry is replaced and an older link is removed. We are not asking you to review or endorse our protocol — only what the platform documents. What we have read, and where we stopped fsync(2) here causes "all modified data and attributes of fildes to be moved to a permanent storage device", then warns that after power loss an application "may find that only some or none of their data was written". fcntl(2) says of F_FULLFSYNC that "data that had been fsync'd on the same device before is guaranteed to be persisted when this call returns", and lists APFS as supported. rename(2) "guarantees that an instance of new will always exist, even if the system should crash in the middle of the operation". In what we read, we did not find a statement connecting a successful synchronisation call on a descriptor that refers to a directory with the durability of a name added, removed or replaced in that directory. We are not claiming no such statement exists — only that we did not find one, which is why we are asking. Three questions, independent of one another Q1 — How are these calls supported on a directory descriptor? On APFS, how are fsync(2) and fcntl(fd, F_FULLFSYNC) supported when fd refers to a directory (for example one obtained with O_DIRECTORY)? Please treat the two calls separately, since they carry different documented guarantees. "Supported", "not supported" and "not specified for this use" are all useful answers to us. Q2 — If such a call succeeds, what does it cover? If the call in Q1 returns successfully, which changes are guaranteed to have been completed — the directory's own attributes; the entries added, removed or replaced; related metadata? We are asking for the documented scope, not the implementation. Q3 — Is there a documented sequence an application can rely on? Is there a sequence of calls that Apple documents for an application that needs the name resulting from a rename() to survive power loss before it publishes its next state? If so, we would appreciate the reference, the conditions it depends on — filesystem, device, call ordering — and its stated limits. If there is no public commitment of this kind, we would rather be told so plainly, together with whatever level you are able to confirm, including "this is not currently specified" if that is the accurate answer. One distinction we do not want to get wrong rename(2) uses the word crash. We do not want to read a statement about crash behaviour as one about power loss, since the two can differ at the device layer. If a documented guarantee covers one and not the other, that distinction is exactly what we need. We also note the device-level caveat in the same manual page — certain drives "have also been known to ignore the request to flush their buffered data" — and we are not asking you to speak for any particular drive. Environment macOS 26.3, build 25D125, APFS — read on our own development machine and reported here as such; not independently verified by a third party. Deliberately outside this request A rename() between two different directories touches a source directory and a target directory. Whether a guarantee would have to cover both is tracked separately and is not asked here, so that an answer about one directory is not read as covering two. We have not fixed where the temporary file lives, and we are not asking you to choose that layout. Nor do we assume your answer is independent of it: if any of the above depends on whether the source and target directories are the same directory or two different ones, please say so explicitly. We would rather be told the answer is conditional than read an unconditional answer into it.

A user of my app reported that it is slower when enumerating a large number of files on APFS compared to HFS+. Online I can only find information that this is expected for rotational hard disks, but apparently APFS should be optimized for SSDs and hence the observed performance doesn't make sense. I used the code below to enumerate a folder hierarchy with about 100'000 files. I ran it several times on both APFS and HFS+ to minimize differences due to caching. On APFS the last runs took about 4.5 seconds, while on HFS+ the last runs took about 1.3 seconds. How can this big difference be explained? Is APFS really slower than HFS+ when enumerating files on SSDs? let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.canChooseFiles = false if openPanel.runModal() == .cancel { return } let resourceKeys: [URLResourceKey] = [.isDirectoryKey, .fileSizeKey, .creationDateKey, .contentModificationDateKey, .fileIdentifierKey, .isSymbolicLinkKey, .isHiddenKey, .isUserImmutableKey, .attributeModificationDateKey] let enumerator = FileManager.default.enumerator(at: openPanel.urls[0], includingPropertiesForKeys: resourceKeys) { url, error in print(error) return true }! let date = Date() var i = 0 for case let url as URL in enumerator { let _ = try? url.resourceValues(forKeys: Set(resourceKeys)) i += 1 if i % 10000 == 0 { print(i) } } print(-date.timeIntervalSinceNow)

Hi everyone. I've been at this for about 9 hours already but I just needed to ask this somewhere where somebody with experience might pop up. As usual, I left my iPhone backing up its photos and videos to a Photos library in an APFS 1TB Western Digital HDD drive. Today I woke up with an error window saying that the drive is corrupted in some way. Here are the steps that followed: 1- Tried to mount the drive in Disk Utility -> doesn't work 2- Ran first aid in Disk Utility -> doesn't work 3- fsck_apfs with multiple different options in Terminal -> doesn't work 4- Used ddrescue to clone the corrupted hard drive to a 2TB drive -> worked fine with no unreadable/corrupt sectors. 5- I downloaded the WD Drive Utilities and the quick drive test passed -> no error. 6- Called Apple Support (shout out to Imelda for being incredibly nice and experienced) but it seems the only solution is to erase the drive or contact WD. This is not an option for me since it's got my photos library from the last decade. I had a backup in another drive but it's very out of date. I just bought a NAS to transfer it all to a safer place, so the timing for this to happen is the worst case. 7- I noticed that in the Library folder in my Mac, I got a 1.3GB Photos library with many thumbnails of the pictures I was importing last night. The filename is Syndication.photoslibrary. Here's the log from fsck_apfs fsck_apfs Log After all the steps I took, it seems to me that: A- The hard drive is completely fine hardware-wise, evidenced by points 4 and 5. So I would assume that WD can't really help me recover my data. B- The "only" thing that's broken is the apfs_root. So my question is if there is some sort of way to reconstruct the root tree somehow. I would assume that this structure is only partially broken and that there are addresses that it should point to properly, that can support some sort of more involved recovery process. I tried reading the APFS documentation but I'm currently very emotionally distressed at the potential loss of my data that I can't parse that information right now. Does anybody have any clue if something can be done about this? Some sort of script? Literally anything. Many thanks in advance. Best, Andres PS: Please let me know if this forum is the appropriate place for this question. I'm mostly posting here since I feel this is a more advanced subject and I need all the help I can get.

Hi, we're seeing a panic when we SIGSTOP the logd pid. panic(cpu 2 caller 0xfffffe0020e9a364): userspace watchdog timeout: no successful checkins from logd (0 induced crashes) in 120 seconds You may ask "well why would you do that?" and the answer is that we're seeing panics from watchdog/logd when we hammer the diskIO for a download/write (APFS sparse file creation) operation in our software. Is it normal to see this?

macOS has the clonefile*() calls to create a new file that's a clone of an existing file, but is it possible to clone only parts of an existing file into a different existing file? Linux (FICLONERANGE) and Windows (FSCTL_DUPLICATE_EXTENTS_TO_FILE) both provide this functionality. I previously filed FB12737014 with this request.

Hello, I have a raw device number, as an input, for external usb/thunderbolt device (i.e. for /dev/disk9 - it is 9). And I want to format it to APFS or read/confirm APFS FS type if it is already formatted. But I can see that APFS container/volume have another disk number (i.e /dev/disk10) in compare with for my raw disk. Is there a guaranteed way to match raw disk number to underlying APFS container/volume disk number? May be some API? Or just add +1 to raw disk number for getting APFS container/volume disk device number?

Hello! Some colleagues and work on Jujutsu, a version control system compatible with git, and I think we've uncovered a potential lock contention bug in either APFS or the Darwin kernel. There are four contributing factors to us thinking this is related to APFS or the Kernel: jj's testsuite uses nextest, a test runner for Rust that spawns each individual test as a separate process. The testsuite slowed down by a factor of ~5x on macOS after jj started using fsync. The slowdown increases as additional cores are allocated. A similar slowdown did not occur on ext4. Similar performance issues were reported in the past by a former Mercurial maintainer: https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/. My friend and colleague André has measured the test suite on an M3 Ultra with both a ramdisk and a traditional SSD and produced this graph: (The most thorough writeup is the discussion on this pull request.) I know I should file a feedback/bug report, but before I do, I'm struggling with profiling and finding kernel/APFS frames in my profiles so that I can properly attribute the cause of this apparent lock contention. Naively, I ran xctrace record --template 'Time Profiler' --output output.trace --launch /Users/dbarsky/.cargo/bin/cargo-nextest nextest run, and while that detected all processes spawned by nextest, it didn't record all processes as part of the same inspectable profile and didn't really show any frames from the kernel/APFS—I had to select individual processes. So I don't waste people's time and so that I can point a frame/smoking gun in the right system, how can I can use instruments to profile where the kernel and/or APFS are spending its time? Do I need to disable SIP?

Mac: MacBook Pro 16-inch (Intel, 2019) macOS: Tahoe 26.5.1 I'm trying to determine whether this is expected behavior or a bug. Setup I purchased a new 2TB SSD to use exclusively for Time Machine. Before configuring Time Machine, I manually erased the SSD in Disk Utility and formatted it as: APFS (non-case-sensitive) Encrypted I specifically did not choose APFS (Case-sensitive). What happened After selecting the SSD as a Time Machine destination and allowing macOS to prepare the disk, I later checked the volume information and found: File System Personality: Case-sensitive APFS and: APFS Volume Disk (Role): Backup Name: Brad Mac Backups SSD (Case-sensitive) The volume appears to have been converted to a dedicated APFS Backup volume and is now reported as case-sensitive. Additional observations After backups complete: tmutil status reports: Running = 0 indicating Time Machine is no longer running. However, Spotlight processes (mds and mds_store) continue accessing the backup volume for many hours afterwards, preventing normal ejection of the SSD. Using: sudo lsof | grep "/Volumes/Brad Mac Backups SSD" shows Spotlight processes holding the drive open. Finder's "Force Eject" works successfully. Questions Is it expected behavior in macOS Tahoe for Time Machine to create a Case-sensitive APFS Backup volume, even when the destination was originally formatted as standard APFS? Has anyone else observed a Time Machine destination changing from APFS (non-case-sensitive) to APFS (Case-sensitive) during setup? Could the case-sensitive APFS format be related to Spotlight continuously indexing the backup volume and preventing normal ejection? Relevant Output diskutil info disk3s2 returns: File System Personality: Case-sensitive APFS and: diskutil apfs list shows: APFS Volume Disk (Role): Backup Name: Brad Mac Backups SSD (Case-sensitive) Mount Point: /Volumes/Brad Mac Backups SSD 1 Any insight would be appreciated, as Apple Support was unable to explain why the backup volume became case-sensitive.

Hi, a user of one of my apps running on his iPhone 15 with the latest iOS reports that he suddenly cannot import or export files anymore. My app allows to save and load databases from iCloud or locally on the iPhone. This is done using buttons on a main menu which are not reacting anymore for this user. He still can use buttons which trigger functions not requiring file access (like printing data from the database). So far, it is an isolated case (1 of about 500 users reporting this behaviour) but I cannot find an explanation. Has anybody ever seen something like this? Thanks for any ideas/help.

We see a major delay for the first open("disk.img", O_RDONLY); we perform. If it helps, we use clonefile() to copy a sparsed image. if (-1 == (fd = open(path, (mode & O_ACCMODE) | O_CLOEXEC))) return -1; 1791 Thread_1071327 DispatchQueue_1: com.apple.main-thread (serial) 1791 start (in dyld) + 6076 [0x189f72b98] 1791 main (in anka_image) + 20 [0x102171bb8] 1791 clp_main (in libpolicy.dylib) + 2120 [0x102a49eac] 1790 process_info (in anka_image) + 68 [0x1021723f4] + 1790 vdsk_open (in libvdsk.dylib) + 92 [0x1021d90e8] + 1790 vdsk_open_native (in libvdsk.dylib) + 164 [0x1021d91c0] + 1790 open (in libsystem_kernel.dylib) + 64 [0x18a2dd6a4] + 1790 __open (in libsystem_kernel.dylib) + 8 [0x18a2d2678] What advice do you have for diagnosing what is causing the first open to do this? Is this some sort of security scan happening? Indexing?

When a File Provider extension (NSFileProviderReplicatedExtension) mounts a Linux server via SFTP, remote directories containing files that differ only in case (e.g., "README" and "readme") are not represented correctly. The framework silently renames one file locally via the before-bounce mechanism, even though the extension reports both items with distinct identifiers and correct filenames. NSFileProviderActions.h states: "Collision checks should be case insensitive even if the filesystem or file provider might allow two coexisting filenames differing only by their case." This check runs in the framework before writing to disk. Placing the domain on a case-sensitive APFS volume via NSFileProviderDomain(displayName:userInfo:volumeURL:) does not help — the volume passes eligibility but the collision check still applies. This breaks any File Provider extension that mounts case-sensitive filesystems where case-variant filenames are common (especially git repositories). Is there any way to opt out of the case-insensitive collision check per domain? A supportsCaseSensitiveNames property on NSFileProviderDomain would solve this.

Hi, I am developing instant snapshot backup solution for macOS using Endpoint Security. We have stumbled upon a Kernel Panic when using "fclonefileat" API. We are catching a kernel panic on customer machines when attempting to clone the file during ES sync callback: panic(cpu 0 caller 0xfffffe002c495508): "apfs_io_lock_exclusive : Recursive exclusive lock attempt" @fs_utils.c:435 I have symbolized the backtrace to know it is related to clone operation with the following backtrace: apfs_io_lock_exclusive apfs_clone_internal apfs_vnop_clonefile I made a minimal repro that boils down to the following operations: apfs_crash_stress - launch thread to do rsrc writes static void *rsrc_write_worker(void *arg) { int id = (int)(long)arg; char buf[8192]; long n = 0; fill_pattern(buf, sizeof(buf), 'W' + id); while (n < ITERATION_LIMIT) { int file_idx = n % NUM_SOURCE_FILES; int fd = open(g_src_rsrc[file_idx], O_WRONLY | O_CREAT, 0644); if (fd >= 0) { off_t off = ((n * 4096) % RSRC_DATA_SIZE); pwrite(fd, buf, sizeof(buf), off); if ((n & 0x7) == 0) fsync(fd); close(fd); } else { setxattr(g_src[file_idx], "com.apple.ResourceFork", buf, sizeof(buf), 0, 0); } n++; } printf("[rsrc_wr_%d] done (%ld ops)\n", id, n); return NULL; } apfs_crash_es - simple ES client that is cloning the file (error checking omitted for brevity) static std::string volfsPath(uint64_t devId, uint64_t vnodeId) { return "/.vol/" + std::to_string(devId) + "/" + std::to_string(vnodeId); } static void cloneAndScheduleDelete(const std::string& sourcePath, dispatch_queue_t queue, uint64_t devId, uint64_t vnodeId) { struct stat st; if (stat(sourcePath.c_str(), &st) != 0 || !S_ISREG(st.st_mode)) return; int srcFd = open(sourcePath.c_str(), O_RDONLY); const char* cloneDir = "/Users/admin/Downloads/_clone"; mkdir(cloneDir, 0755); const char* filename = strrchr(sourcePath.c_str(), '/'); filename = filename ? filename + 1 : sourcePath.c_str(); std::string cloneFilename = std::string(filename) + ".clone." + std::to_string(time(nullptr)) + "." + std::to_string(getpid()); std::string clonePath = std::string(cloneDir) + "/" + cloneFilename; fclonefileat(srcFd, AT_FDCWD, clonePath.c_str(), 0); { dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 1 * NSEC_PER_SEC), queue, ^{ if (unlink(clonePath.c_str()) == 0) { LOG("Deleted clone: %s", clonePath.c_str()); } else { LOG("Failed to delete clone: %s", clonePath.c_str()); } }); } close(srcFd); } static const es_file_t* file(const es_message_t* msg) { switch (msg->event_type) { case ES_EVENT_TYPE_AUTH_OPEN: return msg->event.open.file; case ES_EVENT_TYPE_AUTH_EXEC: return msg->event.exec.target->executable; case ES_EVENT_TYPE_AUTH_RENAME: return msg->event.rename.source; } return nullptr; } int main(void) { es_client_t* cli; auto ret = es_new_client(&cli, ^(es_client_t* client, const es_message_t * msgc) { if (msgc->process->is_es_client) { es_mute_process(client, &msgc->process->audit_token); return respond(client, msgc, true); } dispatch_async(esQueue, ^{ bool shouldClone = false; if (msgc->event_type == ES_EVENT_TYPE_AUTH_OPEN) { auto& ev = msgc->event.open; if (ev.fflag & (FWRITE | O_RDWR | O_WRONLY | O_TRUNC | O_APPEND)) { shouldClone = true; } } else if (msgc->event_type == ES_EVENT_TYPE_AUTH_UNLINK || msgc->event_type == ES_EVENT_TYPE_AUTH_RENAME) { shouldClone = true; } if (shouldClone) { if (auto f = ::file(msgc)) cloneAndScheduleDelete(f->path.data, cloneQueue, f->stat.st_dev, f->stat.st_ino); } respond(client, msgc, true); }); }); LOG("es_new_client -> %d", ret); es_event_type_t events[] = { ES_EVENT_TYPE_AUTH_OPEN, ES_EVENT_TYPE_AUTH_EXEC, ES_EVENT_TYPE_AUTH_RENAME, ES_EVENT_TYPE_AUTH_UNLINK, }; es_subscribe(cli, events, sizeof(events) / sizeof(*events)); } Create 2 terminal sessions and run the following commands: % sudo ./apfs_crash_es % sudo ./apfs_crash_stress ~/Downloads/test/ Machine will very quickly panic due to APFS deadlock. I expect that no userspace syscall should be able to cause kernel panic. It looks like a bug in APFS implementation and requires fix on XNU/kext side. We were able to reproduce this issue on macOS 26.3.1/15.6.1 on Intel/ARM machines. Here is the panic string: panic_string.txt Source code without XCode project: apfs_crash_es.cpp apfs_crash_stress.cpp Full XCode project + full panic is available at https://www.icloud.com/iclouddrive/0f215KkZffPOTLpETPo-LdaXw#apfs%5Fcrash%5Fes

System-wide deadlock in removexattr from revisiond / APFS We're experiencing a deadlock on certains systems when our software is installed, which is causing side effects in our process (and likely others) such as blocked queues and increased memory usage. According to the spindump, revisiond appears to be holding an exclusive lock within the kernel. Process: revisiond [426] UUID: 5E9B9E04-984B-31AD-A4FF-A1A90B7D53A1 Path: /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/Support/revisiond Codesigning ID: com.apple.revisiond Shared Cache: 25AE5A2A-FE2A-3998-8D4E-F3C5C6E6CEB6 slid base address 0x189834000, slide 0x9834000 (System Primary) Architecture: arm64e Parent: launchd [1] UID: 0 Sudden Term: Tracked Memory Limit: 50MB Jetsam Priority: 40 Footprint: 6225 KB Time Since Fork: 1740319s Num samples: 940 (1-940) Num threads: 5 Note: 1 idle work queue thread omitted [...] Thread 0xc0616d 940 samples (1-940) priority 46 (base 4) last ran 241692.754s ago 940 start_wqthread + 8 (libsystem_pthread.dylib + 7068) [0x189d0ab9c] 940 _pthread_wqthread + 292 (libsystem_pthread.dylib + 11852) [0x189d0be4c] 940 _dispatch_workloop_worker_thread + 692 (libdispatch.dylib + 85356) [0x189b65d6c] 940 _dispatch_root_queue_drain_deferred_wlh + 292 (libdispatch.dylib + 87156) [0x189b66474] 940 _dispatch_lane_invoke + 440 (libdispatch.dylib + 45048) [0x189b5bff8] 940 _dispatch_lane_serial_drain + 944 (libdispatch.dylib + 42420) [0x189b5b5b4] 940 _dispatch_client_callout + 16 (libdispatch.dylib + 113364) [0x189b6cad4] 940 _dispatch_call_block_and_release + 32 (libdispatch.dylib + 7004) [0x189b52b5c] 940 ??? (revisiond + 168768) [0x10494d340] 940 ??? (revisiond + 165940) [0x10494c834] 940 ??? (revisiond + 40264) [0x10492dd48] 940 ??? (revisiond + 56680) [0x104931d68] 940 <patched truncated backtrace> 940 removexattr + 8 (libsystem_kernel.dylib + 23768) [0x189cd1cd8] *940 ??? (kernel.release.t6000 + 15240) [0xfffffe000886fb88] *940 ??? (kernel.release.t6000 + 1886348) [0xfffffe0008a3888c] *940 ??? (kernel.release.t6000 + 7730436) [0xfffffe0008fcb504] *940 ??? (kernel.release.t6000 + 2759592) [0xfffffe0008b0dba8] *940 ??? (kernel.release.t6000 + 2808244) [0xfffffe0008b199b4] *940 apfs_vnop_removexattr + 1044 (apfs + 474512) [0xfffffe000be8d4d0] *940 decmpfs_cnode_set_vnode_state + 80 (kernel.release.t6000 + 2945816) [0xfffffe0008b3b318] *940 IORWLockWrite + 184 (kernel.release.t6000 + 496184) [0xfffffe00088e5238] *940 ??? (kernel.release.t6000 + 494624) [0xfffffe00088e4c20] *940 ??? (kernel.release.t6000 + 619452) [0xfffffe00089033bc] *940 ??? (kernel.release.t6000 + 624472) [0xfffffe0008904758] The bulk of the other processes are waiting for that lock. (suspended, blocked by krwlock for reading owned by revisiond [426] thread 0xc0616d) (blocked by krwlock for writing owned by revisiond [426] thread 0xc0616d) Around the time of the event, these messages were logged by revision: 2026-03-06 18:49:37.781673-0500 0x16b7 Error 0x7f92f364 426 14 revisiond: [com.apple.revisiond:default] [ERROR] CSCopyChunkIDsForToken failed for 41639 2026-03-06 18:49:37.781716-0500 0x16b7 Error 0x7f92f365 426 14 revisiond: [com.apple.revisiond:default] [ERROR] updateEntry for new entry <private> failed 2026-03-06 18:49:37.781738-0500 0x16b7 Error 0x7f92f366 426 14 revisiond: [com.apple.revisiond:default] [ERROR] no entry for '<private>' 2026-03-06 18:49:37.781754-0500 0x16b7 Error 0x7f92f367 426 14 revisiond: [com.apple.revisiond:default] [ERROR] failed assembleInfoForOffset for fsid 16777234 fileid 359684022 offset 0 size 14334 (path <private>) Our agent uses Endpoint Security Framework to monitor events, and provide anti-tamper functionality for installed components and processes. While several EndpointSecurity calls appear in the spindump stack traces, we don't have any evidence that any calls from revisiond were blocked. What we'd really like to to understand what that lock is (appears to be decompressing an object on an APFS volume), what revisiond and APFS are doing with it, and what might cause it to deadlock. Of note, one of our processes is also waiting on that lock, one thread for reading and the other for writing. This issue affects machines running several macOS versions (15.x, 26.x). The machine in the examples is running macOS 26.3 (25D125)

Testing copyfile on a folder on an external volume (which takes a bit a of time) I'm running into an issue where copyfile gets to the end of the operation and then just fails. In the callback I can see that the failure occurs on a .DS_Store file inside the folder. So for a .DS_Store it is simple enough for me to just ignore the error and return COPYFILE_SKIP but the somewhat more concerning issue here is that the true error reason is seemingly not reported? In the callback if I read errno it is 0. When copyfile returns it returns -1 after I return COPYFILE_QUIT (and errno is 0) so I don't know what the error is or the appropriate way to handle it. For .DS_Store just skipping seems reasonable but when copying a folder it may be appropriate to get the true failure reason. But checking the last path component of source path seems like a hack way to handle errors. If a file in the copying folder with important user data I can't just silently skip it - it isn't clear to me how I should properly proceed in a situation where I can't get the actual reason for the failure.

The man page of copyfile sates the following: COPYFILE_CLONE [..] Note also that there is no support for cloning directories" COPYFILE_CLONE_FORCE [...] Note also that there is no support for cloning directories: if a directory is provided as the source, an error will be returned. Now the man page for clonefile: > Cloning directories with these functions is strongly discouraged. Use copyfile(3) to clone directories instead. -- So am I to enumerate the content of a directory build subfolders along the way in the target destination and clone each file inside individually? If I recall NSFileManager seems to clone a large directory instantly (edit actually I remembered wrong NSFileManager does not do this. Finder seems to copy instead of clone as well). On further inspection, clonefile states that it can do this, but it is discouraged. Interesting. I wonder why. If src names a directory, the directory hierarchy is cloned as if each item was cloned individually. However, the use of clonefile(2) to clone directory hierarchies is strongly discouraged. Use copyfile(3) instead for copying directories. P.S. - Forgive me if I posting this in the wrong category, I couldn't find a "category" in the list of available categories on these forums that seems appropriate for this question.

Hi, I'm encountering a weird issue on iOS that happens: for files with diacritics in their name, like "Gòmez.pdf" or "Télé.mp4", when the iPhone or iPad main language is not set to English, if the file has been created with a relatively low-level Unix function like fopen() or copyfile(). Then, the file cannot be previsualized using QuickLook or opened using other apps. Most of the time it fails silently, but on some occasions I get the following error message: "You do not have permission to save the file "filename.pdf" in the folder "myFolder"". The issue is present in, at least, iOS 16 and 26. It seems worse in iOS 26. It seems that all three conditions are required, I don't see the issue when the iPhone or iPad is set to use English as the main language. I also don't see the issue if I rename the files in the Files app. I'm probably doing something wrong, but what can it be? (it's kind of weird that my recommendation for users becomes: if you want to use international characters in your file names, you need to set the iPad language to English...)

As a part of the video editing app I’m working on, I want to efficiently copy a folder of resources on the same (local) filesystem. Because iOS is on APFS, cloning (CoW) is an option. I read the documentation for clonefile(2) which states that cloning a folder works but is strongly discouraged. I did a small sample project which demonstrates that using clonefile on a folder works correctly and is 10× faster than using FileManager’s copyItem method. My questions: The main one I’m interested in: Why is using clonefile for a folder strongly discouraged? Is FileManager using cloning behind the scenes? Or more exactly how guaranteed are we it will use it? (I know it does, I tried manually cping the resources and it was thousands of times slower.)

I am slowly converting an Objective C with C program to Swift with C. All of my menus and dialog boxes are now in Swift, but files are still opened and closed in Objective C and C. The following code is Objective C and tries to open two files in the same directory with two related names after getting the base of the name from a Save Panel. The code you see was modified by ChatGPT 5.0, and similar code was modified by Claude. Both LLMs wrote code that failed because neither knows how to navigate Apple’s sandbox. Does anybody understand Apple’s sandbox? I eventually want to open more related files and do not want the user to have to click through multiple file dialog boxes. What is the best solution? Are the LLMs just not up to the task and there is a simple solution to the Objective C code? Is this easier in Swift? Other ideas? Thanks in advance for any help. (BOOL)setupOutputFilesWithBaseName:(NSString*)baseName { NSString *outFileNameStr = baseName; if (outFileNameStr == nil || [outFileNameStr length] == 0) { outFileNameStr = @"output"; } // Show ONE save panel for the base filename NSSavePanel *savePanel = [NSSavePanel savePanel]; [savePanel setMessage:@"Choose base name and location for output files\n(Two files will be created: one ending with 'Pkout', one with 'Freqout')"]; [savePanel setNameFieldStringValue:outFileNameStr]; if (directoryURL != nil) { [savePanel setDirectoryURL:directoryURL]; } if ([savePanel runModal] != NSModalResponseOK) { NSLog(@"User cancelled file selection"); return NO; } // Get the selected file URL - this gives us security access to the directory NSURL *baseFileURL = [savePanel URL]; // Get the directory - THIS is what we need for security scope NSURL *dirURL = [baseFileURL URLByDeletingLastPathComponent]; // Start accessing the DIRECTORY, not just the file BOOL didStartAccessing = [dirURL startAccessingSecurityScopedResource]; if (!didStartAccessing) { NSLog(@"Warning: Could not start security-scoped access to directory"); } NSString *baseFileName = [[baseFileURL lastPathComponent] stringByDeletingPathExtension]; NSString *extension = [baseFileURL pathExtension]; // Create the two file names with suffixes NSString *pkoutName = [baseFileName stringByAppendingString:@"Pkout"]; NSString *freqoutName = [baseFileName stringByAppendingString:@"Freqout"]; NSURL *pkoutURL = [dirURL URLByAppendingPathComponent:pkoutName]; NSURL *freqoutURL = [dirURL URLByAppendingPathComponent:freqoutName]; NSLog(@"Attempting to open: %@", [pkoutURL path]); NSLog(@"Attempting to open: %@", [freqoutURL path]); // Open the first file (Pkout) globalFpout = fopen([[pkoutURL path] UTF8String], "w+"); if (globalFpout == NULL) { int errnum = errno; NSLog(@"Error: Could not open Pkout file at %@", [pkoutURL path]); NSLog(@"Error code: %d - %s", errnum, strerror(errnum)); if (didStartAccessing) { [dirURL stopAccessingSecurityScopedResource]; } return NO; } NSLog(@":white_check_mark: Pkout file opened: %@", [pkoutURL path]); // Open the second file (Freqout) globalFpfrqout = fopen([[freqoutURL path] UTF8String], "w+"); if (globalFpfrqout == NULL) { int errnum = errno; NSLog(@"Error: Could not open Freqout file at %@", [freqoutURL path]); NSLog(@"Error code: %d - %s", errnum, strerror(errnum)); fclose(globalFpout); globalFpout = NULL; if (didStartAccessing) { [dirURL stopAccessingSecurityScopedResource]; } return NO; } NSLog(@":white_check_mark: Freqout file opened: %@", [freqoutURL path]); // Store the directory URL so we can stop accessing later secureDirectoryURL = dirURL; return YES; }

Hi, We can easily get drive throughput using the iostat command, but it only outputs plain text that needs to be parsed, and I’m not sure if the format or column order is consistent across macOS versions. Is there any API that provides the same disk I/O metrics that iostat reports, but in a way that can be safely called from a notarized app?

I am having a rare crash when calling FileHandle(forWritingTo:) initializer with a file that does not exist. In the documentation, I see that the expected behaviour is to return nil, but in my app, in rare cases I have a Crash. My code that causes the crash is if let handle = try? FileHandle(forWritingTo: logFile) { Is it a known behaviour ? should I test if the file exist before calling FileHandle(forWritingTo:) ? Shareable_2025-09-01_05-32-28.3051.crash