Errant behavior in distribution of '.DS_Store' files

Question

I am currently using macOS Ventura. According to "About this Mac", I am using ver. 13.6.5. Like some of you, I also employ a NAS (network file server⁺) for backups and general file storage. My NAS is made by a company called Synology. The Mac and the Synology have something in common: they both produce files that can result in malfunctions in other programs/systems. I typically encounter these malfunctions when performing system backups with the rsync program; e.g. cannot delete empty folder.

Is there a proven, reliable, method for stopping macOS from spewing these disruptive .DS_Store files all over my NAS? And while it's "off-topic" to ask if there is a remedy for the Synology NAS' behavior, if anyone has heard of a solution, I'd like to hear from you.

Answer 1

I'm with Gilby and can confirm the following: When DSDontWriteNetworkStores is active (TRUE) on a system, the .DS_Store files on network volumes are not processed.

That means:
a) If a folder on a network share contains a .DS_Store file, it will not be read by the client and will be completely ignored.
b) No .DS-Store files will be created or modified by a client performing actions in Finder that would normally do that (to store viewing preferences for this folder/window inside the folder)

That does not mean:
a) that .DS_Store files are not exisiting or forbidden to be written. If you copy a locally created folder to the network share, that folder will contain a .DS_Store file. And that will also be copied to the network share.
b) that .DS_Store files are hunted down by a process to delete them.

Conclusion:

a) use defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE preferably as root on a system to set this for all users
b) use a cronjob on the server to recursively scan the shares for .DS_Store files and delete them.

Answer 2

Starting with macOS Sierra (10.12), Apple has taken extra steps to hide the presence of .DS_Store files; i.e. since 10.12 they can not be seen as hidden files... they simply cannot be seen at all in Finder. I do not know why, except that this tactic seems to fit in with Apple's generally secretive MO. There has been much speculation and investigation into the details and content of the .DS_Store file, but AFAIK no one has completely "cracked the code" on this file.

I have 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 function/purpose, but I do wish they would disclose their reasoning. That said, I agree that Apple's intemperate dispersion of DS_Store files is a bad thing as it may cause malfunctions in software/systems performing necessary or desirable functions.

In this "support" document Apple implies they have provided a method to limit the intemperate dispersion of .DS_Store files from their OS. Unfortunately for users, this document is deceptively worded. Note that the command Apple recommends in this document contains the term DSDontWriteNetworkStores. If that command is taken at face value, it certainly implies that this command stops Apple's OS from Writing .DS_Store files. But in the preceding paragraph Apple writes, "you can prevent macOS from reading .DS_Store files"! Apple, disingenuously, never admits that we users cannot prevent macOS from writing .DS_Store files. Very slick piece of writing... very deceptive - cowardly even!

Apple's "support" document contains further ambiguities and deception. It says "for browsing network folders such as Server Message Block (SMB) shares". No mention is made of other network file systems; e.g. NFS or SSHFS. I have not tested these other network file systems here as Synology uses SMB by default. And speaking of testing, results of my testing of the Apple Solution for .DS_Store follows:

IAW Apple's online instructions (published Feb 29 of 2024):

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

Test the Command:

Since Apple doesn't actually tell us much, we should verify the setting. After the write above, let's now do a read:

defaults read com.apple.desktopservices DSDontWriteNetworkStores
1

Huh - 1... I wondered what that meant in "Apple-speak", so went a bit further to verify:

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool FALSE
defaults read com.apple.desktopservices DSDontWriteNetworkStores
0
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
defaults read com.apple.desktopservices DSDontWriteNetworkStores
1

So - Apparently TRUE == 1, and FALSE == 0

Now, just for grins we'll try this with a different user - a member of the Administrator group:

seamus@fumier ~ % su sdemora
Password: 
sdemora@fumier ~ % defaults read com.apple.desktopservices DSDontWriteNetworkStores
2024-03-23 21:21:24.357 defaults[33484:4740417] 
The domain/default pair of (com.apple.desktopservices, DSDontWriteNetworkStores) does not exist 

# surprising! but apparently the default value does not exist until it is written! 

sdemora@fumier ~ % defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
sdemora@fumier ~ % defaults read com.apple.desktopservices DSDontWriteNetworkStores
1

And so, in conclusion we see that the command syntax works as claimed. But let's see if the command actually stops distribution of the .DS_Store files.

Does Apple's Command Actually Limit Writing .DS_Store Files?

I have set up a small demonstration using rsync on a Synology NAS (DSM ver 7.2-64570 Update 3). The demonstration involves a small folder with 2 subfolders, and a dozen files on the local drive of my Mac (aka fumier). These local files are the SOURCE in this rsync demo. I rsync these local files/folders to the rsync daemon running on the Synology NAS; this copies the files to Synology's file system. The Synology server's filesystem is the DESTINATION in this demo.

IOW, this is a very typical (but simplified) configuration for backing up one's local drive to a network file system using rsync.

Following is the script I run on my Mac to perform the actual rsync backup:

#!/opt/local/bin/bash
PATH=/opt/local/libexec/gnubin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
cd '/Users/jmoore/scripts/rsync-bkup'

SRC_Demo='/Users/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 running the script above, following is the Finder view of the rsync'd files on the SynologyNAS:

Now for the moment of truth... did Apple's defaults command prevent the propogation of .DS_Store files from the Mac to the NAS? Since we can't actually see .DS_Store files in Finder, we'll need to use something else - the find command will work for this:

seamus@fumier /Volumes/backups/fumier % find . -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 positive that Apple's DSDontWriteNetworkStores command did not inhibit the propagation of .DS_Store files from the Mac to the Synology file server.

The Verdict:

Apple's defaults command did not prevent the propagation of .DS_Store files

This is fairly disappointing - even considering that "it's Apple". But of course you're free to draw your own conclusions regarding Apple's intentions here. Following are a few other points to ponder:

1. Perhaps Apple considers this to be a "non-covered" form of network connection?
2. If you actually read Apple's announcement, you may note the following statement: "you can prevent macOS from reading .DS_Store files on SMB shares". Odd that - naming a command to prevent reading as "DSDontWriteNetworkStores"!?
3. As it turns out, Apple's online instructions for limiting the spew of .DS_Store have been circulating for more than 10 years, discussed in reputable forums, including hundreds of Q&A here on SE. The fact that Apple re-published it on Feb 29 of 2024 is puzzling, but not surprising in its arrogance.
4. Or... perhaps I overlooked something? If so - please let me hear from you!