DS_Store cleanup for v6


Recommended Posts

I'm planning on upgrading to v6 sometime in the next week or so and trying to get at least a rough list of dockers and such that will also need to be installed. With the expanded functionality of v6, many of the features I currently use unMenu for are handled except for DS_Store cleanup. I see that unMenu is being updated to v6 so I'm guessing that cleanup is still supported there, but it seems like a waste of resources to install it just to run one package. Is there a simpler way in v6 to accomplish the cleanup on a cron schedule?

Link to comment

someone posted a shell script for this, probably it's similar or even the same as you used from unmenu.

 

i'm simply running it in a telnet session. but someone could probably write a plugin to include it into the gui

 

#!/bin/bash
# Version .1 - remove .DS_Store files and ._* files

# ========================================================================== #
# Program Body                                                               #
# ========================================================================== #
echo "Removing .DS_Store and ._ files"
find /mnt/ -name .DS_Store -or -name "._*" -print -delete

Link to comment

someone posted a shell script for this, probably it's similar or even the same as you used from unmenu.

 

i'm simply running it in a telnet session. but someone could probably write a plugin to include it into the gui

 

#!/bin/bash
# Version .1 - remove .DS_Store files and ._* files

# ========================================================================== #
# Program Body                                                               #
# ========================================================================== #
echo "Removing .DS_Store and ._ files"
find /mnt/ -name .DS_Store -or -name "._*" -print -delete

 

Just tried this and it deleted all of the "._.DS_Store" but left all of the ".DS_Store" files

Link to comment

Alright I changed the code to this and it removed both the .DS_Store & ._.DS_Store

 

Just a thought, it may be a good idea to change this script to just find those files and display them first and then give an option to review the files before they get deleted. Or you could just run two scripts:

 

Find_DS_Stores.sh

#!/bin/bash
# Version .1 - find .DS_Store files and ._* files

# ========================================================================== #
# Program Body                                                               #
# ========================================================================== #
echo "Finding .DS_Store and ._.DS_Store files"
find /mnt/ -name .DS_Store -print
find /mnt/ -name "._*" -print

 

Then once you agree with those findings you could run this.

 

Remove_DS_Stores.sh

#!/bin/bash
# Version .1 - remove .DS_Store files and ._* files

# ========================================================================== #
# Program Body                                                               #
# ========================================================================== #
echo "Removing .DS_Store and ._.DS_Store files"
find /mnt/ -name .DS_Store -print -delete
find /mnt/ -name "._*" -print -delete

  • Like 1
Link to comment
  • 2 months later...

Hi...I also just moved to v6 today and I am also looking for a plugin or simple docker file for this. 

 

Had it in 5 and it worked great. When you use Mac's you get A LOT of these.  Even though you can hide them in 6, they still take space. I really thought that v6 would have a way to do this built in. (When I read about hiding them, my mind went right to removing them. So I thought it was.)

Link to comment

This is a simple shell script that I use.

 

#!/bin/bash
# ========================================================================== #
# Program Body                                                               #
# ========================================================================== #
((!$#)) && echo No Directory supplied! && exit 1

dir="$@"
echo $dir

echo "Removing .DS_Store files"
find "$dir" -name ".DS_Store" -exec rm '{}' \; -print

echo "======================="
echo "Removing ._ files"
find "$dir" -name "._*" -exec rm '{}' \; -print

 

I run it as ./rmdotstore.sh /mnt/user/directoryname

 

I don't run it against the whole tree because I've seen ._ filenames inside plex and there may be others as well.

 

Kevin.

Link to comment

This is a simple shell script that I use.

 

#!/bin/bash
# ========================================================================== #
# Program Body                                                               #
# ========================================================================== #
((!$#)) && echo No Directory supplied! && exit 1

dir="$@"
echo $dir

echo "Removing .DS_Store files"
find "$dir" -name ".DS_Store" -exec rm '{}' \; -print

echo "======================="
echo "Removing ._ files"
find "$dir" -name "._*" -exec rm '{}' \; -print

 

I run it as ./rmdotstore.sh /mnt/user/directoryname

 

I don't run it against the whole tree because I've seen ._ filenames inside plex and there may be others as well.

 

Kevin.

I'm not very good at this, but it's my understanding that this could be used to run as a cron job with a directory specified. Not sure how to set it up though?

Link to comment
  • 2 months later...
  • 5 weeks later...

even better would be an integration into unRAID itself... because then it would not

 

1/ spin up all drives on a regular basis just to do a "expensive" lookup for these files (and deleting them as found) – thinking of my backup scenario with several 100 tsds of files...

2/ do this action for the sake of doing it, not knowing that sometimes no such files are newly created - and be a total waste of time/energy

3/ be implemented manually (and be forgotten then) and maybe once (with a update, change, etc.) get's broken or makes problems

 

i would hope for an implementation by lime tech into unRAID itself. it maybe could be implemented like: whenever such mac-typically (hidden) files should be written to disk, unRAID (silently) accepts those file creations (but never writes them to disk). that would allow the mac programms to work as expected and filters out these files – even better: they never get written to disk, they never waste space, and they never need to be killed afterwards. the only exception i would think about is for the "TimeMachine"-share.

 

 

 

 

  • Upvote 1
Link to comment

i would hope for an implementation by lime tech into unRAID itself. it maybe could be implemented like: whenever such mac-typically (hidden) files should be written to disk, unRAID (silently) accepts those file creations (but never writes them to disk). that would allow the mac programms to work as expected and filters out these files – even better: they never get written to disk, they never waste space, and they never need to be killed afterwards. the only exception i would think about is for the "TimeMachine"-share.

I don't have a mac (and don't know about the problems associated with having those files stored on a nas), but I don't think its a very good idea for any OS to ignore valid write requests for files.  Just opening up a huge can of worms.
Link to comment

i'm myself a mac-user every since... well, long time ago.

 

using macs natively means, you run on apple's HFS(+/journaled) file-systems. one of the features is, that files can have two forks (data/ressource). it was introduced (if i remember right) to allow the storage of additional metadata, while keeping full compatibility to the older version of HFS. but, most important, you never have to deal with them on apples side, because of the native file-system (os-implementation). not during creation, deletion, copying, or any kind of interaction (also because you don't see them).

 

but, if those files get copied, created, moved, transferred from a mac-system (with active native apple file-system/or native software) on an different non-mac-native file-system, the destination file-system doesn't know anything about these metadata and simply creates those as separated files. i'm not even sure, if the mac uses these files while accessing them over the network on a file-server not using native apple file-systems.

 

i'm not recalling any problem with a file, if the ._* part of it got deleted, or wasn't accessible/available while it got accessed. some backup-software even doesn't write those files to non-HFS file-systems, because they don't support them natively.

 

anyway, it's on the other side a long, old story and apple didn't change a thing all over these years. they added newer features in newer versions of the protocol, but never dropped older ones or changed, how they behave on non-apple file-systems.

Link to comment

Some of those files, actually most of them, store things like window position and settings.

If you turn them off writing them to servers you will notice every time you will have to open a directory/folder every time even though you left it open when disconnecting. And some are Apple desktop data bases. I think very few are used for actual file meta data now if any unless you're running some very old stuff, which I do at times.

Link to comment
  • 5 months later...
  • 3 years later...

This can be solved on the Mac end of things. Just enter the following command on your Mac: 

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

*Important: just remember to restart Finder as well:

killall Finder

Source: https://www.techjunkie.com/stop-ds-store-files-mac-network/

  • Like 1
Link to comment
  • 2 years later...
On 9/27/2019 at 11:24 PM, mkfyr65z said:

This can be solved on the Mac end of things. Just enter the following command on your Mac: 

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

*Important: just remember to restart Finder as well:

killall Finder

Source: https://www.techjunkie.com/stop-ds-store-files-mac-network/

Thank you for this super annoying having these files littered all over my other non-Mac machines.  I have had these DS files actually break certain programs when they dump into a configuration folder on certain dockers.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.