[ad_1]
Beginning with macOS Sierra (10.12), Apple has taken further steps to cover the presence of .DS_Store information; i.e. since 10.12 they can’t be seen as hidden information… they merely can’t be seen in any respect in Finder. I have no idea why, besides that this tactic appears to slot in with Apple’s typically secretive MO. There was a lot hypothesis and investigation into the main points and content material of the .DS_Store file, however AFAIK nobody has utterly “cracked the code” on this file.
I’ve presumed innocence wrt Apple’s creation and long-term use of the .DS_Store file. I’ve made this assumption in ignorance of the file’s perform/function, however I do want they’d disclose their reasoning. That mentioned, I agree that Apple’s intemperate dispersion of DS_Store information is a dangerous factor as it might trigger malfunctions in software program/techniques performing essential or fascinating capabilities.
In this “assist” doc Apple implies they’ve supplied a way to restrict the intemperate dispersion of .DS_Store information from their OS. Sadly for customers, this doc is deceptively worded. Notice that the command Apple recommends on this doc accommodates the time period DSDontWriteNetworkStores. If that command is taken at face worth, it definitely implies that this command stops Apple’s OS from Writing .DS_Store information. However within the previous paragraph Apple writes, “you possibly can forestall macOS from studying .DS_Store information”! Apple, disingenuously, by no means admits that we customers can not forestall macOS from writing .DS_Store information. Very slick piece of writing… very misleading – cowardly even!
Apple’s “assist” doc accommodates additional ambiguities and deception. It says “for shopping community folders comparable to Server Message Block (SMB) shares“. No point out is manufactured from different community file techniques; e.g. NFS or SSHFS. I’ve not examined these different community file techniques right here as Synology makes use of SMB by default. And talking of testing, outcomes of my testing of the Apple Answer for .DS_Store follows:
IAW Apple’s on-line directions (revealed Feb 29 of 2024):
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
Check the Command:
Since Apple does not truly inform us a lot, we should always confirm the setting. After the write above, let’s now do a learn:
defaults learn com.apple.desktopservices DSDontWriteNetworkStores
1
Huh – 1… I questioned what that meant in “Apple-speak”, so went a bit additional to confirm:
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool FALSE
defaults learn com.apple.desktopservices DSDontWriteNetworkStores
0
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
defaults learn com.apple.desktopservices DSDontWriteNetworkStores
1
So – Apparently TRUE == 1, and FALSE == 0
Now, only for grins we’ll do this with a distinct person – a member of the Administrator group:
seamus@fumier ~ % su sdemora
Password:
sdemora@fumier ~ % defaults learn com.apple.desktopservices DSDontWriteNetworkStores
2024-03-23 21:21:24.357 defaults[33484:4740417]
The area/default pair of (com.apple.desktopservices, DSDontWriteNetworkStores) doesn't exist
# shocking! however apparently the default worth doesn't exist till it's written!
sdemora@fumier ~ % defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
sdemora@fumier ~ % defaults learn com.apple.desktopservices DSDontWriteNetworkStores
1
And so, in conclusion we see that the command syntax works as claimed. However let’s examine if the command truly stops distribution of the .DS_Store information.
Does Apple’s Command Really Restrict Writing .DS_Store Information?
I’ve arrange a small demonstration utilizing rsync on a Synology NAS (DSM ver 7.2-64570 Replace 3). The demonstration entails a small folder with 2 subfolders, and a dozen information on the native drive of my Mac (aka fumier). These native information are the SOURCE on this rsync demo. I rsync these native information/folders to the rsync daemon operating on the Synology NAS; this copies the information to Synology’s file system. The Synology server’s filesystem is the DESTINATION on this demo.
IOW, it is a very typical (however simplified) configuration for backing up one’s native drive to a community file system utilizing rsync.
Following is the script I run on my Mac to carry out the precise rsync backup:
#!/decide/native/bin/bash
PATH=/decide/native/libexec/gnubin:/decide/native/bin:/decide/native/sbin:/usr/native/bin:/usr/bin:/bin:/usr/sbin:/sbin
cd '/Customers/jmoore/scripts/rsync-bkup'
SRC_Demo='/Customers/seamus/RsyncDemo/'
DST_Demo='rsync://seamus@SynologyNAS-1/backups/fumier/Rsync_Demo'
rsync -rlAtgoDiv --password-file=./pwd-f $SRC_Demo $DST_Demo
exit 0
After operating the script above, following is the Finder view of the rsync'd information on the SynologyNAS:
Now for the second of fact… did Apple’s defaults command forestall the propogation of .DS_Store information from the Mac to the NAS? Since we won’t truly see .DS_Store information in Finder, we’ll want to make use of one thing else – the discover command will work for this:
seamus@fumier /Volumes/backups/fumier % discover . -name '.DS_Store' -print
./Rsync_Demo/.DS_Store
./Rsync_Demo/RsyncDemoA/folderA/folderA-1/.DS_Store
./Rsync_Demo/RsyncDemoA/folderA/folderA-2/.DS_Store
./Rsync_Demo/RsyncDemoA/folderA/.DS_Store
./Rsync_Demo/RsyncDemoA/.DS_Store
./Rsync_Demo/RsyncDemoB/folderB/folderB-1/.DS_Store
./Rsync_Demo/RsyncDemoB/folderB/folderB-2/.DS_Store
./Rsync_Demo/RsyncDemoB/folderB/.DS_Store
./Rsync_Demo/RsyncDemoB/.DS_Store
What we see above is proof optimistic that Apple’s DSDontWriteNetworkStores command didn’t inhibit the propagation of .DS_Store information from the Mac to the Synology file server.
The Verdict:
Apple’s defaults command didn’t forestall the propagation of .DS_Store information
That is pretty disappointing – even contemplating that “it is Apple”. However after all you are free to attract your personal conclusions concerning Apple’s intentions right here. Following are just a few different factors to ponder:
- Maybe Apple considers this to be a “non-covered” type of community connection?
- In the event you truly learn Apple’s announcement, chances are you’ll word the next assertion: “you possibly can forestall macOS from studying .DS_Store information on SMB shares”. Odd that – naming a command to forestall studying as “DSDontWriteNetworkStores”!?
- Because it seems, Apple’s on-line directions for limiting the spew of
.DS_Storehave been circulating for greater than 10 years, mentioned in respected boards, together with a whole bunch of Q&A right here on SE. The truth that Apple re-published it on Feb 29 of 2024 is puzzling, however not shocking in its conceitedness. - Or… maybe I ignored one thing? In that case – please let me hear from you!
[ad_2]