# Hacking Darwin to remove .DS_Store



## aqsalter (Oct 23, 2002)

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


----------



## jwalk76 (Oct 24, 2002)

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.


----------



## scruffy (Oct 24, 2002)

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.


----------



## michaelsanford (Oct 24, 2002)

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


----------



## jwalk76 (Oct 24, 2002)

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


----------



## Tigger (Oct 24, 2002)

> _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. *


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 ._*


----------



## michaelsanford (Oct 24, 2002)

Licht für dich?


----------



## michaelsanford (Oct 24, 2002)

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.


----------



## gatorparrots (Oct 24, 2002)

*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'.


----------



## aqsalter (Oct 24, 2002)

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


----------



## gatorparrots (Oct 24, 2002)

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


----------



## aqsalter (Oct 24, 2002)

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>


----------



## gatorparrots (Oct 25, 2002)

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.


----------



## gatorparrots (Oct 25, 2002)

*aqsalter*--It seems as if someone as annoyed as you wrote a utility to do as you ask:

*CleanUp smb mess*
"CleanUp smb mess" is an applescript droplet that will clean up Windows shares mounted thru the Mac OS X samba client by removing all "._*" files, .DS_Store files and .Trashes folders on all the volumes and folders dragged on it.
http://www.versiontracker.com/moreinfo.fcgi?id=15918&db=mac


----------



## aqsalter (Oct 28, 2002)

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


----------



## strobe (Oct 30, 2002)

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.


----------



## Koelling (Nov 2, 2002)

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?


----------



## aqsalter (Nov 3, 2002)

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>


----------



## strobe (Nov 4, 2002)

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


----------



## rvamerongen (Nov 16, 2002)

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.


----------



## kilowatt (Nov 17, 2002)

Personally, I'm hoping apple will come up with something like the BFS (Be's File System). We're allready getting pretty close, with Journaling and such, but if we had Metadata, we could kiss most HFS[+] issues goodbye for ever.

Course, makes you wonder what would happen when you copy those files to another file system.

This is a finder-specific issue, and it wouldn't be too dificult for apple to provide a "Don't store finder view settings on remote volumes" option in the System Preferences. Wouldn't surprise me at all if they did that as a sort of quick-fix.

The entire idea of placing view setting files (preferences, imo) in a world-readable enviroment is very single-user-thinking. 

Consider this, lets say you prefer to have icons aranged by importance to your part of a given project. The project resides on a remote server. The project has ten people who all prefer to keep their part of the project at the top of the icon view. Asside from assiging different folders for each member, there is no great solution. Each member will get the same viewing preferences as the previous member. 

Really, view preferences should be stored in a sort of cache, similar to how web browsers store cookies, history, and page content. And this should be a client-specific thing. Each client should cache (to a set limit) remote volume view preferences locally. This would save a ton of trouble - 1) you wouldn't have to have those darn windows users complain, 2) you don't have to have your prefs re-written each time another mac user loggs into a cross-platform share, and 3) its more multi-user friendly. 

And if they're cached locally, you could easily have them (the .ds files) compressed until a remote volume is mounted.

Lots to think about...


----------



## strobe (Nov 17, 2002)

BFS supports arbitrary file attributes, but it lacks support for FileIDs which is a deal-breaker.


----------



## kilowatt (Nov 17, 2002)

But using metadata, couldn't you just add a field for FileID?


----------



## strobe (Nov 18, 2002)

> _Originally posted by kilowatt _
> *But using metadata, couldn't you just add a field for FileID? *



No.

Basically HFS+ treats the file name as a file attribute and the FileID as the file itself. To find a file by path you look it up in the catalog then get it's ID. Same with folders.

The whole point of the FileID is you can access a file by its ID. Thus when the path changes you can still access the file. Also the path can be considered variable, not constant. (unlike POSIX apps).


----------



## kilowatt (Nov 26, 2002)

You could allways have a cron job build an HFS+ fileid database, and for those files that are marked as dynamic, they can be indexed. Every night, you would get a fresh list for those legacy apps that rely on file id's. It wouldn't be too hard to build a legacy file handeler.

Bottom line though, if we want to step into the field of high-performance file systems, I think apple will either have to re-invent the wheel, or we'll have to adopt another file system and do without file id's. 

Granted, my above fake file-id scheme would be slow and annoying, but... so is classic. File ID's are cool, but I think users and our new unix system can be trusted to place files in semi-logical locations


----------



## LordOphidian (Nov 26, 2002)

Kilowatt, if we add more metadata to a filesystem, then we would just magnify the problem of having to create hidden files on filesystems that don't support the richness of our metadata.  Its not really a HFS/HFS+ specific problem, its a general metadata/non-metadata problem.  That said, Be did have some pretty slick ways of getting some of the metadata back that you lost in transition to other fs's.

Also, you can't trust users to do _anything_ the way you want them to.  You can hope, but that won't stop them from doing something stupid/harmful.


----------



## cabbage (Nov 26, 2002)

I think we should start a new polls that says

Hacking Windows to remove thumbs.db

Man those files are really bugging me whenever I copy anything over from my XP box to OS X.


----------



## wiz (Nov 26, 2002)

how about schedule a task in darwin to delete .DS_Store files automatically from perticular folders!!!

wouldn't that work?


----------



## aqsalter (Nov 26, 2002)

X-Wizer...

Actually a cron job to delete all .* files from /Volumes every 10 mins would work, but I think to do it properly would require a little bit of work as you would have to be careful not to delete "non-MacOS" files... (ie files that start with ".", but not created by OS X)

You could maybe set up a cron job to run the "Clean SMB mess" on selected volumes (a really good idea), but I don't know how to do this.

"Clean SMB mess" is really fast too... I don't know how it works, but it can clean huge volumes in seconds - whereas the "find / - name .... " method can take _ages_....


----------



## kilowatt (Nov 27, 2002)

Actually, on a meta data file system, metadata is stored *in* the file. Not as an external file.

But, otoh, I have no idea what would happen as a bfs file is copied over to an NTFS share. 'Guess there are a few posabilities.


----------



## jwalk76 (Nov 27, 2002)

> _Originally posted by X-wiZeroS _
> *how about schedule a task in darwin to delete .DS_Store files automatically from perticular folders!!!
> 
> wouldn't that work? *



yes, here is a simple shell script called rmdot that I placed in every users $PATH on my system.  each user only has to type rmdot or have a cron job execute rmdot and his/her home directory will be rid of any .DS_Store, .Trashes or ._* files...

```
find ~ -name '\._*' -exec rm {} \;
find ~ -name '\.DS_Store' -exec rm {} \;
find ~ -name '\.Trashes' -exec rm -Rf {} \; 2> /dev/null
```

Edit: This happens on my Slackware box, where my webserver is, not on my Mac, where i assume these files are important...


----------



## LordOphidian (Nov 27, 2002)

> _Originally posted by kilowatt _
> *Actually, on a meta data file system, metadata is stored *in* the file. Not as an external file.
> *


Actually its stored *with* the file.  That is if the fs supports storing (rich)metadata for files.


> *
> But, otoh, I have no idea what would happen as a bfs file is copied over to an NTFS share. 'Guess there are a few posabilities. *


Yep, thats the problem.  I believe with Be it would just do like OS 9 and let the metadata get striped.  With OS X, Apple decided that losing the resource forks (not technically metadata) wasn't an acceptable solution, since OS X supports having many different file systems be local, and trying to use a carbon app on a msdos fs or NTFS would break the app if there wasn't a way to store the data as seperate files.  Instead they store it in the ._* files, and the finder stores its metadata in .DS_Store files.  Which are the problem we are talking about here.  If you added more metadata you would have to expand either the number of files you create, or the scope of the .DS_Store file.

The optimal solution is to provide a pref that lets the user choose if he wants to write out the hidden files if the volume he is writing to is remote.   If the volume is local it would probably be best to assume its going to stay local and write out the files to preserve compatablity.


----------



## strobe (Nov 27, 2002)

This is why I hate UNIX. Everything is a file at a static path. You change the path, things start to break. It's STUPID!

The argument that filesystems shoudln't support metadata because old filesystems do not is ludicrous. I mean ancient UNIX filesystems ony had capital letters in the filename, does that mean no file should have small letters, let alone unicode names?! I mean DOS filesystems are limited to the 8.3 format for crissakes.

I say move FORWARD. Screw filesystems, screw the file metaphor! Files SUCK! All I want is my data, why does it have to be arranged in a contiguous bytestream in a particular format? That isn't how I deal with data within a document.

If we must have a filesystem I won't do it without FileIDs. Without FileIDs all you're left with is the fragile static paths of doom.

As for performance, dealing with static paths has HINDERED my productivity much more than any degredation of peroformance you could surmise is due to not using ext2 or whatever. Let's get back to the human<->computer bottleneck Apple!


----------



## aqsalter (Nov 27, 2002)

Stobe:

What you are talking about is a filesystem as a database. You query the database for the file you want, it gives you the file. You assign meta data as per your own needs - good examples: iTunes song database, iPhoto photo database.

So I think you should not worry - Apple are on to your concept, but so are MS and Linux... Don't worry!!


----------



## strobe (Nov 27, 2002)

Stop calling it a file then |-p


----------



## LordOphidian (Nov 27, 2002)

> _Originally posted by strobe _
> *This is why I hate UNIX. Everything is a file at a static path. You change the path, things start to break. It's STUPID!
> *


Agreed.  Static paths are very useful, and with OS X the way we have it now you have the power of both static POSIX paths and unique file id's.


> *
> The argument that filesystems shoudln't support metadata because old filesystems do not is ludicrous. I mean ancient UNIX filesystems ony had capital letters in the filename, does that mean no file should have small letters, let alone unicode names?! I mean DOS filesystems are limited to the 8.3 format for crissakes.
> 
> I say move FORWARD. Screw filesystems, screw the file metaphor! Files SUCK! All I want is my data, why does it have to be arranged in a contiguous bytestream in a particular format? That isn't how I deal with data within a document.
> *


Agreed. Here is a good discussion about metadata.

But this is even more tangental to the original question than the original talk on metadata.  We are talking about ways of storing metadata, resource forks, etc. on fs's that we know don't support them and can't do anything about.


----------



## dirtbag (Apr 24, 2003)

I transfer files from my iBook to my 'doze @ work with a USB flash drive.


----------



## dirtbag (Apr 24, 2003)

Sorry 'bout that...here's my whole message:
I transfer files from my iBook to my 'doze @ work with a USB flash drive. These unix files used to drive me nuts when they appeared on the PC. I set up a search for them in the StartBar and delete them before I even open the disc. Neither the PC nor my Book seem to notice.


----------

