Seems that the /bin/cp command has an arg for accomplishing something similar to the Finder based copy.
cp -c : copy files using clonefile(2)
Also, The f_fsid related observations/content in my first comment on this post is not correct. Thanks @eskimo for correcting me regarding that st_ino and f_fsid are not related.
Post
Replies
Boosts
Views
Activity
Greetings,
It turns out that feature-info I was looking for is about an APFS feature called Copy-On-Write-Clones . I was able to view documentation on it so I am good for now.
For Finder copy-operations, with destination being the same volume, APFS seems to be creating the new file with different meta-data but the file shares the same data-content as the original. During my tests, I found that copying a 1GB file on the same volume via Finder did not decrease the available space on the Volume by 1GB.
What was cool was that if I appended to the new File, then the disk-available-space gets decreased by only the bytes that were appened to the new File. So, the Sharing of data-content/blocks continues even post the edit.
I ran some more tests with Finder and /bin/cp command.
1). As expected, the same Finder copy operation on HFS+ volumes has a different behavior than Finder copies on APFS.
2). However when comparing Finder-based-copy operation with cp-command copy operation on MacOS-APFS, the behavior strangely differs when it comes to CopyOnWriteClones. Not sure why, but /bin/cp command is generating new files without sharing the Data blocks of original and the space-saving is not occurrinig; Finder based copies on the other hand are exibiting the space-saving behavior.
Thanks,
Vikram.S.Warraich.
Thanks @eskimo.
Any documentation regarding MacOS Finder/FS's Space-Saver feature or how it is implemented ?
@eskimo , Thanks a lot. Issue seems fixed in MacOS 14.2 build 23C63.
@eskimo , Is there a way to request raising the priority of this issue ? There hasn't been any movement on the ticket FB13342978 yet. We are getting more reports of our customers running into this issue.
Thanks @eskimo .
Created FB13342978.
@eskimo , I was able to repro the issue yesterday and inspect the logs. Sharing the possible ways below.
1). One way that It occurs for me is if I modify the system time to a future date via SystemPreferences and reboot. Issue occurs on next login.
2). Another way it occurred was if I set the FDA setting in System Preferences and then quit the tccd process owned by the logged-in user, and rebooted.
3). There are other possibilities too as my colleague can repro it without having to run steps 1 or 2.
Attaching some relevant Log snippets from around when the issue occurs.
SysDiagnosisLogSnippets.txt
Please confirm if If above repro steps are known issues and covered by FB13084552 or FB13194377 ? Else, I can create a ticket for those scenarios.
Regards.
@eskimo ,
What is the best way to view the description of FB13084552 or FB13194377. When I try to look either of them up in the FeedbackAssistant, there are no search results. I might not have access to view them possibly ?
@eskimo ,
Thanks for your reply.
If it helps, I was able to observe the issue yesterday without requiring to REBOOT. The relevant FullDiskAccess Item for SystemExtension in SystemPreferences got unchecked while being logged in after after 4-5 hours. This is on 14.2 Beta 23C5030f.
Also, I don't have access to FB13084552 . Could you please share any information about its relevancy to the issue I described ?
Regards,
Vikram.S.Warraich
Regarding my previous comment...
Issue was observed on MacOS 14.1 .
Issue occurs when FullDiskAccess is provided via the SystemPreferences->Privacy&Security->FullDiskAccess setting.
AFAIK, Issue does not occur when FullDiskAccess is provided via MDM.
The Full Disk Setting items in SystemPrefs get unchecked/disabled automagically after some reboots when the issue occurs.
Thanks.
Hello,
Any update regarding this ? I am running into this issue too.
Issue:
Full Disk Access setting for a Network/System Extension is getting cleared after a reboot on MacOS Sonoma.
Issue does not occur with every reboot.
Not sure if it gets cleared before/during/after the reboot yet.
Including some relevant logs.
<BEFORE/DURING REBOOT>
error 2023-10-27 16:45:19.897037 -0700 tccd codeRequirementFromStaticCode:0x13f60a890 SecStaticCodeCheckValidity() fails: -67061
error 2023-10-27 16:45:19.898763 -0700 tccd Failed to post com.apple.tcc.access.changed notification (9)
default 2023-10-27 16:45:19.900235 -0700 launchd exited due to SIGKILL | sent by tccd[164] during system shutdown
default 2023-10-27 16:45:19.900243 -0700 launchd internal event: EXITED, code = 0
<STARTINGUP/AFTER REBOOT>
error 2023-10-27 16:45:56.160784 -0700 runningboardd memorystatus_control error: MEMORYSTATUS_CMD_CONVERT_MEMLIMIT_MB(-1) returned -1 22 (Invalid argument)
error 2023-10-27 16:45:56.394864 -0700 cfprefsd Couldn't open parent path due to [2: No such file or directory]
fault 2023-10-27 16:45:56.406378 -0700 mDNSResponderHelper Couldn't read values in CFPrefsPlistSource<0x156e07600> (Domain: com.apple.security, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: No): accessing these preferences requires user-preference-read or file-read-data sandbox access
error 2023-10-27 16:45:56.440578 -0700 kernel System Policy: dirhelper(252) deny(1) file-write-unlink /private/var/folders/zz/zyxvpxvq6csfxvn_n00000sm00006d/T/com.apple.geod/42B44A5C-6F69-441A-B4AF-F249709618EF
There are some errors from endpointsecurityd
error 2023-10-27 16:45:57.590703 -0700 endpointsecurityd File was empty: /Library/SystemExtensions/EndpointSecurity/.started_es_jobs.plist
fault 2023-10-27 16:45:58.372379 -0700 endpointsecurityd Rejected invalid Extension Point com.apple.AppleMediaServicesUI.EngagementViewExtension targeting DEPRECATED NSExtension infrastructure!
error 2023-10-27 16:45:59.482270 -0700 trustd Connection 1: received failure notification
error 2023-10-27 16:45:59.482284 -0700 trustd Connection 1: failed to connect 1:50, reason -1
error 2023-10-27 16:45:59.482285 -0700 trustd Connection 1: encountered error(1:50)
error 2023-10-27 16:45:59.482537 -0700 trustd Task <20F8D91C-D278-4001-A127-FD168B888BB6>.<1> HTTP load failed, 0/0 bytes (error code: -1009 [1:50])
.....
[self.extensionContext conformsToProtocol:auxHostProtocol.protocol] - /AppleInternal/Library/BuildRoots/11aa8fb2-5f4b-11ee-bc7f-926038f30c31/Library/Caches/com.apple.xbs/Sources/ExtensionFoundation/ExtensionFoundation/Source/NSExtension/NSExtensionSupport/EXExtensionContextImplementation.m:283: Class NEFilterPacketExtensionProviderContext does not conform to aux host protocol:
......
error 2023-10-27 16:46:02.717195 -0700 VTDecoderXPCService send_message_with_reply_sync(): XPC_ERROR_CONNECTION_INVALID for message 0x600002db0180
error 2023-10-27 16:46:02.717195 -0700 VTDecoderXPCService TCCAccessRequest_block_invoke: Connection invalid
Regards,
Vikram.S.Warraich
More Information.
We are seeing identical behavior on Catalina.
There are 2 Primary Groups being reported for Mobile Login users.
Can someone please Answer if this behavior is by Design ?
More Information:
I just now Observed the issue when the Primary group for the Mobile Login User on the AD Server is switched to a different Group on the AD Server.
I don't know why MacOS implements it this way, but there seem to be 2 instances of that user in 2 different NODES in DirectoryServices. These instances have the EXACT SAME UniqueID.
One of these NODES is the /Local/Default node, which I assume is for the scenario when the Mobile Login user is not connected.
The other NODE is the /ActiveDirectory/domain node, which might be referred to for the when-connected-to AD scenario.
After switching the Primary group on the AD Server for that user, only one of the above NODE is getting updated.
The above results in the account getting 2 Instances of Primary Group when the Tool is querying via the OpenDirectory/DirectoryServices Framework.
It is unclear to me if this behavior is a Big Sur issue OR occurs on earlier MacOSes OR is by Design this way.