Hacking Darwin to remove .DS_Store

What to do with .DS_Store?

  • Kill!! Kill!! Kill!! (it should be noted the problem is only really on "non" OS X systems - where th

  • They're not that bad.

  • What's a .DS_Store?

  • I quite like the little critters.

  • Stop picking on Apple, they work hard and give us good software - Why does everyone nitpick?

Results are only viewable after voting.
A

aqsalter

Registered
It might not seem like a big deal, but until I can use OS X without creating .DS_Store and other "." files in external directories I'm not going to use OS X at work. (Full-stop. I'm not going to create more work/hassle for my work collegues - they are already a little suspicious of Macs and then every network directory I touch creates "extra" useless files)

I'm wondering if anybody has heard of a hack to remove this (it could even remove it from the entire system, or I could disable it while I'm at work). I'm sure there is a way - I was even thinking about Unsanity APE which allows you to recode Cocoa API calls... Or hacking the source of Darwin (if that is where it resides)...

Let's kill this bug so we and many other people (link) can get on with using an (almost) otherwise perfect system...

Adam Q Salter
 
amen brother. i write code on my mac and then place it on my slackware server via samba. i'm getting really sick of having to clean out all of these files. other than .DS_Store, i also get a ._* equivalent of any file that i drag over (a samba issue, i believe), so in reality, transferring 20 files from my Mac creates 41 on the slackware box. i've been meaning to write a perl script to clean out the directories on command, but i never think of it when i have the time.
 
I suspect it's the Finder that's doing this. In my ~/src directory, where the finder has never looked, there is no .DS_Store. My Desktop has both .DS_Store and .localized, neither of which I put there.
 
I've been told that the ._* files is Windows' way of expressing the mac resource fork, which is why they appear. It's not Samba doing that, because I had a flash USB drive that I used with OS X and XP and I had those stupid ._* files everywhere too. It is a big pain, but I can't say whether it's Darwin or the Finder that does that, or some other middle-layer of the OS I don't even know about...
 
michaelsanford,

i am proud to say that i have never owned a machine with Micro$oft Window$. these ._* files appear on my Slackware Linux box when i transfer files via Samba. so, i guess it is a Mac-based problem but not specifically Samba or Window$ related. i guess i need to get cracking on my afore-mentioned cron/perl script to automate removal of these little annoyances...
 
Originally posted by michaelsanford
I've been told that the ._* files is Windows' way of expressing the mac resource fork, which is why they appear.
Click to expand...
As far as I know this is the way Mac OS X saves the Resource fork on File systems other than HFS/HFS+.

If you put files on a WebDAV server, it also saves these ._* files.

If you don't show invisible files on Windows, you won't see all these files, because at least Apple thought about hiding these little things. .DS_Store was visible till Mac OS 10.x, don't know which revision it was, but at some revision they hid it. This also has to be the revision that started encoding the resource fork as ._*
 
But on a serious note, the problem isn't so much that they are visible, it's that it clutters up a folder. So if you try to copy the folder, it copies these things too.

Hey actually it would be a simple matter to write an applescript to remove them...if you can mount windows volumes locally.
 
sudo find / -name ".DS_Store" -exec rm {} \;

This will remove all .DS_Store files on your boot disk. To change the volume, replace '/' with the appropriate '/Volumes/volumename'.
 
Yeah, I kind of guessed that all those ._* files contain icon data etc (resource fork stuff) but I don't care if I can't change the icons on a Windows/Linux share (although I recognise that maybe some other people do)

I might use the above suggested "sudo find ..." as a cron job on the affected volumes, but I just want an option to turn this off.... Doesn't seem that unfair or unreasonable to me. Besides which the find is going to take _ages_ on a big share drive and probably slow things down heaps.

I also think this is Finder issue as only the Finder creates these things (other programs that do copies don't) or "cp" from the Terminal.

I guess the other solution is to use one of the other "Finder" replacements... Any suggestions here?

No this is really annoying for me, as someone who wants to use Macs in the enterprise - it puts PC users out and that's the last thing I need. Creating a ._* file for every file I copy is just too much (on my work network at least).
 
Path Finder (nee SNAX) appears to be the file manager of choice to replace the Finder.

Rather than choosing the cron/script approach to removing the .DS_Store files, why don't you you create a MS-DOS-formatted partition or drive image and work off of it with your files? Then you won't have a resource fork to get in the way and annoy your colleagues.

Also, rather than using the Finder for browsing SAMBA shares, why not use FTP or SMB Browse (or equivalent)?

(Granted this is an issue with the Finder in a heterogeneous computing environment that Apple should fix, but these are all possible workarounds for you).
 
Path finder looks good... and Samba browser is a better Finder "network browse" (a problem I didn't know I had ;)

I'm going to evaluate Path finder and see if I like it (and whether it creates any extraneous files).

Mr Perez:- as this is partly an idealogy problem I don't actually expect Apple to ever fix this. (ie they don't see there is a problem IMHO) Therefore I'm also going to hold my breath for a hack.

<sigh>

...

<deep breath>
 
If Apple wants to make inroads into IT departments and large corporations (which they do), they will make their software "play nice" with other standards. I am hopeful that now they have the OS somewhat stable and the code somewhat optimized, they will be able to go back and refine the interface and address these types of issues. Standards compliance is the next big hurdle for them, and eliminated the HFS+ resource fork issues should be a paramount priority for them.
 
<exhale...>

<pant>
<pant>

;)

There's even a comment so that other computers don't see the "." files when browsing your computer.

To hide items, you need to make changes to smb.conf. The two you want are "hide dot files = yes", "hide files = /.bash*/Network Trash Folder/TheFindByContentFolder/TheVolumeSettingsFolder/Virex SpeedScan/etc,etc...". These are the properties you want to set. Full details on their use should be on samba.org. Note that turning on either of these (or both) will impact on samba performance as it needs to make decisions on whether to show or hide each item.
Click to expand...
 
The real problem is the lack of any open standard to deal with arbitrary file attributes. I mean next you will all complain that HFS+ doesn't follow the 8.3 DOS filename format.
 
can anyone tell me what this .DS_store does? I've noticed it before but just ignored it. I do a lot of coding on my mac and then copy it across ssh to a linux server on campus so this is copied with it but it doesn't seem to be too big so It doesn't seem to matter as far as bandwidth is concerned. But as the original post suggested, hacking the system to remove all of them? will it mess with anything?
 
After investigation I believe that the .DS_Store file stores the finder "View" setting- ie column, list or icon - and the other .* files are the resource forks of files on file systems that don't support resource forks (most systems)...
I still feel sure that it must be possible for the system to write to share directories without creating these files... but I have found that you can kill applications by deleting their ".file_name" file. (You can try this by copying an standard Mac app onto a windows share and then deleting the .file_name file - the app is dead - of course this should not affect documents, just Carbon apps)
So if all you do is copy files with no resource forks it can be pretty annoying, but I can see where Apple need to have this functionality in order to keep the system functioning...
<shrug>
 
Step 1) Create filesystem with more or an arbitrary number of file attributes

Step 2) Wait for eunuchs lovers to complain their filesystem doesn't support these attributes natively, ending up with extra invisble files
 
Hi, i saw today this thread.

The best things is to keep them where they needed, this means only remove them where you dont want them. If you remove them everywhere you will get more irritated then to remove them only there where needed. When you b.e share a 'folder' to win users use this.

sudo find /Users/Tilak/Projects/DVD/ -name ".DS_Store" -exec rm {} \;

The line is seen earlier but I show this only to let you see that it also works with a path name to a Folder.
In my case i use it also to make a folder ready to create a disk.img ready for burning.
 
You must log in or register to reply here.
Back
Top