How do I prevent ._ file creation?

**today** · February 5th, 2003, 03:23 AM

I have several Samba (ie, Windows-style) shares on our network. The Macs on our network can finally access them under OSX, which is cool, but they litter them with all sorts of "._blahblah" files.

I need to turn this off. It is creating all these tiny files, each of which consumes 4k, which is the smallest block size on these particular Unix boxes. It starts to add up on shares with 80,000 files on them (they could consume 328MB!).

What's odd is that the Macs obviously don't need these strange files at all. They work just fine on shares without write permissions (and thus, without the ability to create the "._" mess). I'm not sure why they don't come from the factory as good network citizens and have this stuff off by default on non-Mac shares...

-todd-

**Pengu** · February 5th, 2003, 07:00 AM

Uh..
the ._ files are where osx puts the resource fork of a file if it's not on a HFS or HFS+ volume, eg, UFS, or Fat16/32 or NTFS (or any of the linux file systems) Only way to not have these on a non HFS file system is to not have resource forks, which isn't hard with files. they SHOULD be created without them. if you gives files a different application to open with than the system setting, or if images have a thumbnail of themselves as the icon, etc, that will require a resource fork.

**today** · February 5th, 2003, 08:15 AM

Only way to not have these on a non HFS file system is to not have resource forks, which isn't hard with files. they SHOULD be created without them.

They should, but they aren't. The Macs create them for EVERYTHING. MP3 files, text files, SourceSafe (Windows Version Control for Developers) files (!!!). It makes them for directories. It adds temporary item folders and trash folders.

I just tried making the Samba server reject all attempts to make files that begin with "._". Know how the Mac responded to a simple drop&drag copy of a file named "test.rc" (a simple text file)? The Mac made a zero length file called "test.rc" then complained that there was some error about permissions and gave up! Thinking that this might be due to test.rc already having some resource fork attached, I copied a log file from a Samba share (this log file was created by a PC and this share had been previously stripped of all "._" files by hand) to the Mac desktop, then tried copying right back to another Samba share. BZZZZT!!! Same problem as mentioned above. So it is true that the Mac Finder *ALWAYS* makes a "._" file for EVERY file copied to a Samba share, regardless of whether it has a resource fork attached or not. Either that, or the Mac Finder always makes a resource fork for EVERY file, which would end with the same results on the network share.

When I drag MP3 files and text files from Windows to the Samba share, all I get is an MP3 file or a text file. No extra files. I heard some Mac guy crack about the Thumbs.db files that Windows creates. I agree those are silly, but at least they are only created in response to a thumbnail browse operation, and are not created simply by the act of copying files to a network share. Plus, there is only one of them per directory, so it keeps slack space down. And, most importantly, you can EASILY TURN THIS FEATURE OFF!

There is absolutely no reason why the Macs should be creating these extra resource fork files. All the files in questions are just data files. And on a server with a cluster size of 4k, they create a ton of wasted slack space.

This is pretty frustrating. Thanks for reading my rant.

-todd-

**jeb1138** · February 5th, 2003, 10:20 AM

Originally posted by today
This is pretty frustrating. Thanks for reading my rant.

-todd-

Lol! No problem todd, hope it made you feel better!

If it makes you feel better yet, Apple is moving away from resource forks in order to make OS X a better 'Net Citizen'. From Apple's Mac OS X System Overview:

Before Mac OS X and Carbon, application resources were put in the resource fork of the application executable. That policy has now changed. In Mac OS X and for Carbon applications generally, resources should be put in the data fork of a separate resource file, not the resource fork of the executable.
...
As with applications, documents on Mac OS X should have their resources put in the data fork. The reasons for this are the same as the reasons for having application resources in the data fork. It makes it possible to exchange these documents, without loss of resource data, between Macintosh and non-Macintosh systems, including most Web servers.

It's gonna take a little time for backward-compatibility's sake though. And perhaps they'll never move completely away from extra forks, for the reasons that Pengu mentioned.

Anyway, as far as current solutions for your problem, how about:
1. Set up a cron job to get rid of them every once in a while. The Mac's only create a ._ duplicate file when they modify/create a file, right? How many files are your Mac users realistically going to modify/create before you can send the cron job around? What kind of network services are you providing? Is 4,000 reasonable? Is 16MB really that big of a deal? Is that even $0.10 worth of disk space?

2. I'm not sure, but telling your Mac users to use RBrowser Lite to access the Network drive might solve your problem. RBrowser Lite does ftp & etc but it also works great as just a local file browser, and it's free. After the drive is mounted they can access it just like they would in the Finder. I'm not sure how it copies files around so I'm not sure if it would cause the same problem. Using the 'cp' command in the terminal, for example, doesn't create ._ files, I believe.

I know what you mean about the waste of space and the fact that OS X should be a better network citizen in this regard, but given the fact that they Apple is working toward what you want (better network citizenship) it's not really that big of a deal to cope with it for the time being, is it? I guess I've never worked with a LAN where my users might be writing to over 10,000 files on the network though, so I guess I can't judge ya.

Good luck.

**Pengu** · February 5th, 2003, 01:32 PM

cp doesn't can't copy the resource fork as such... If you copy a file with a resouce fork from a HFS volume (where there will be no ._file) to a non-HFS volume using "cp" you will lose the resource fork.
If you do it with the Finder, it will create the ._filename data file to store the resource fork data in.

**jeb1138** · February 5th, 2003, 08:04 PM

Originally posted by Pengu
cp doesn't can't copy the resource fork as such... If you copy a file with a resouce fork from a HFS volume (where there will be no ._file) to a non-HFS volume using "cp" you will lose the resource fork.
If you do it with the Finder, it will create the ._filename data file to store the resource fork data in.

Which is exactly why I said something (maybe RBrowser but I'm not sure) using cp could be good for this situation.

Nothing really essential is stored in resource forks these days anyway, is it?

**today** · February 6th, 2003, 02:39 AM

Set up a cron job to get rid of them every once in a while.

I suppose that is what I'll have to do. I don't know, somehow, this issue has really been a burr up my bum. Doing this sort of hack is frustrating, because I hear the propaganda about Macs having lower TCO. Well, that hasn't been my experience, at least with Unix based servers using free software tools.

When I was running NT and Win2k based Servers, there weren't any issues with the Macs because Microsoft had done an absolute awesome job on their AppleTalk filesharing system. It allowed seamless filesharing between the two worlds while dealing with the resource fork silliness in the proper manner. IE, exposed to Macs, completely invisible to the PCs. It was possible to look at the resource fork on the Server, but even there, it required command-line tools. That's how hidden it was.

I got tired of paying the Microsoft server user tax, so I went to OpenBSD. In Unix land, the AppleTalk stuff is about where Samba was back in 1995. No disrespect to the developers of netatalk, etc, it is just that Samba is pretty highly polished because they have more developers interested in working on that problem. And even netatalk litters the directories with .Apple* and similar stuff, although it is mostly concentrated in one subfolder. It is also separate from Samba, so I can turn the Samba VETO command on dot files.

I guess I'm veering waaaaay off topic here. It is just as an admin, I've never really found the Mac to play well with others unless a Microsoft server was invovled in the transaction. That's why I never understand the TCO arguments.

The Mac's only create a ._ duplicate file when they modify/create a file, right?

Well, yes, that is what I thought, although I've caught an entire subtree that *shouldn't* have been written by any Macs which had all these ._ files in them. Either there is some tool within the Finder that is doing this, or some Mac user of mine accidentally move the entire tree to his drive, then moved it back when they realized the mistake.

How many files are your Mac users realistically going to modify/create before you can send the cron job around? Is 16MB really that big of a deal?

No, you are right. My late night frustration after I had changed all the Samba servers to VETO ._ files and then finding it to not work caused me to go a bit hyperbolic.

I'm not sure, but telling your Mac users to use RBrowser Lite to access the Network drive might solve your problem.

Thanks for the tip, I'll pass it to the Mac people.

-todd-

**michaelsanford** · February 18th, 2003, 11:44 PM

The one-liner, run from the folder you want to clean (also suitable for cron, change the "." to the volume's path):
find . -name ._* -exec rm '{}' ';'