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?

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

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

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

How would I add this script to v6?

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

Same here, just moved to v6 on my backup server and looking to do the same on my media server.

It is nice in v5 not having to interact with it to delete that since my media server is very active recording and deleting TV show every day.

 

I also found this info which may be of interest:

http://superuser.com/questions/306108/disable-creation-of-appledouble-files-on-mac-os-x

 

 

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.

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?

So anyone want to make this into a plugin or docker that we can run when needed?

+1, would be great to have this!

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.

 

 

 

 

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.

You are correct. I think cleaning once a month is enough even for the most used server. If this was a Mac server you could not delete them.... They don't use much memory and if they were hidden better on samba shares it might not be such a annoyance.

 

My thoughts.

I think one issue with these is that you can not delete an "Empty" share from the GUI because of these files even though hidden keep the share from being truly empty.

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.

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.

There is a way to stop these files being written server (UNraid) side

Please see my post here

 

https://lime-technology.com/forum/index.php?topic=49963.0

 

 

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/

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.