wgstarks Posted June 29, 2015 Share Posted June 29, 2015 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? Quote Link to comment
Benni-chan Posted June 29, 2015 Share Posted June 29, 2015 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 Quote Link to comment
archedraft Posted June 29, 2015 Share Posted June 29, 2015 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 Quote Link to comment
archedraft Posted June 29, 2015 Share Posted June 29, 2015 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 1 Quote Link to comment
wgstarks Posted July 4, 2015 Author Share Posted July 4, 2015 How would I add this script to v6? Quote Link to comment
David Bott Posted October 1, 2015 Share Posted October 1, 2015 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.) Quote Link to comment
Russ Uno Posted October 1, 2015 Share Posted October 1, 2015 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 Quote Link to comment
digitalfixer Posted October 1, 2015 Share Posted October 1, 2015 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. Quote Link to comment
wgstarks Posted October 1, 2015 Author Share Posted October 1, 2015 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? Quote Link to comment
squirrellydw Posted December 10, 2015 Share Posted December 10, 2015 So anyone want to make this into a plugin or docker that we can run when needed? 1 Quote Link to comment
smoldersonline Posted January 10, 2016 Share Posted January 10, 2016 +1, would be great to have this! Quote Link to comment
s.Oliver Posted January 10, 2016 Share Posted January 10, 2016 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. 1 Quote Link to comment
Squid Posted January 10, 2016 Share Posted January 10, 2016 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. Quote Link to comment
Thornwood Posted January 10, 2016 Share Posted January 10, 2016 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. Quote Link to comment
Russ Uno Posted January 11, 2016 Share Posted January 11, 2016 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. Quote Link to comment
s.Oliver Posted January 11, 2016 Share Posted January 11, 2016 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. Quote Link to comment
Russ Uno Posted January 11, 2016 Share Posted January 11, 2016 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. Quote Link to comment
SpaceInvaderOne Posted June 24, 2016 Share Posted June 24, 2016 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 Quote Link to comment
mkfyr65z Posted September 28, 2019 Share Posted September 28, 2019 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/ 1 Quote Link to comment
Patriot_Unraider Posted December 15, 2021 Share Posted December 15, 2021 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. Quote Link to comment
Recommended Posts
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.