Hello everyone, I am posting here because I genuinely do not know what else to do, and I hope someone from Apple or someone who has experienced the same issue can help. On October 5, 2026, I paid $99 for the Apple Developer Program. Apple issued an official invoice confirming the charge, but 10 days later, my account is still Pending. Even worse, my account page continues to ask me to purchase the membership again, displaying the following message: "Purchase your membership. To continue your enrollment, complete your purchase now." I have already paid. I should not be asked to pay again for a membership that Apple has already charged me for. Here is what makes this situation even more frustrating: I paid the full $99 membership fee and received an official invoice from Apple. I submitted my passport through the verification link Apple provided. I have sent multiple emails to Apple Developer Support explaining the situation and asking for assistance. I followed up on my existing support case, but I have received absolutely no response to my emails. My application is ready for publication, but I cannot publish it because my membership remains pending. The website says payment processing may take up to 48 hours. It has now been 10 days, and I still have no explanation, no meaningful update, and no resolution. How is a developer supposed to move forward when Apple has taken the payment, requested identity verification, left the account pending, and stopped responding to support requests? I understand that identity verification can take time, but the complete lack of communication is extremely frustrating. Even a simple update explaining what is wrong or what additional information is required would be helpful. I am asking for a clear answer: Is this a payment-processing issue, an identity-verification issue, or a problem with my enrollment? How can I get my existing case reviewed by the Apple Developer Enrollment team as soon as possible? Is there a direct contact channel or escalation process for cases like this? If Apple cannot activate my membership, how can I obtain an explanation and a refund? I do not want to pay twice. I simply want the membership I paid for to be activated so I can publish my application, or to receive a clear explanation and an appropriate refund if activation is not possible. I am posting publicly because my attempts to resolve this privately through multiple support emails have gone unanswered. Has anyone experienced the same issue? Did your account eventually get activated, and how did you get Apple to respond? Any advice or help from someone familiar with Apple Developer enrollment would be greatly appreciated. Thank you.

Can we have on screen finger slide on Duo upcoming update and other related device respectively.

We are developing a security-sensitive local execution system on macOS and need clarification about supported Darwin/APFS filesystem APIs. Our requirement is to create an additional directory entry (hard link) for an existing, authorized regular-file object while retaining its original directory entry. SECURITY REQUIREMENTS The source file has already been opened and its identity verified using a held file descriptor and fstat(). The source must remain the exact same filesystem object (device/inode identity), not a copy or clone. An attacker operating under the same user account may concurrently rename, unlink, or replace the source pathname. The publication operation must not create a hard link to, or otherwise mutate, a substituted source object. The new link must be created within an already-open, authorized destination directory. Unsupported configurations must be detectable before attempting a potentially unsafe publication mutation. The original source directory entry must remain present. We have reviewed linkat(), fclonefileat(), rename-based approaches, filesystem flags, and directory-descriptor-relative operations. The difficulty is that linkat() identifies its source through a pathname. Holding a verified source file descriptor does not appear to guarantee that the pathname still identifies the same object when linkat() performs the mutation. A subsequent fstat() or pathname identity check cannot undo an already-created link to a substituted object. QUESTIONS Does macOS provide a supported public API that creates an additional hard link directly from an existing open file descriptor, without resolving a replaceable source pathname? Does Darwin support an equivalent of Linux linkat() with AT_EMPTY_PATH, or another documented descriptor-based source-linking mechanism? Can any supported macOS filesystem API guarantee that a concurrent same-user replacement of the source directory entry cannot redirect the publication mutation? If descriptor-based hard linking is unavailable, is there a supported filesystem or namespace protection mechanism that prevents same-owner source-entry substitution throughout the operation? Do AT_SYMLINK_FOLLOW, AT_SYMLINK_NOFOLLOW, AT_RESOLVE_BENEATH, AT_RESOLVE_NOFOLLOW_ANY, or related Darwin flags provide any guarantee that the linked source is the previously verified inode rather than a replacement? Are the relevant guarantees dependent on macOS version, APFS volume configuration, filesystem flags, privileges, or entitlements? Is there a supported way to determine whether the required operation and guarantees are available before performing the publication mutation? We are specifically interested in documented and supported APIs, their identity guarantees, availability conditions, and limitations. We are not seeking a workaround based solely on comparing file identities after the operation, copying/cloning the file, or assuming that same-user pathname replacement cannot occur. If no supported public API provides these guarantees, confirmation of that limitation would also be helpful. Thank you.

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.)