Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Prevent .DS_Store file creation on UNIX shares Network
If you mount unix servers via samba you probably end up with .DS_Store files all over the place. A way I found to keep those from showing up is to 'veto' these files in the Samba config. In the [global] section of smb.conf of the server I am mounting I added:
 veto files = /.DS_Store/
[Editor's note: I haven't tested this one yet...]
    •    
  • Currently 2.50 / 5
  You rated: 1 / 5 (6 votes cast)
 
[30,966 views]  

Prevent .DS_Store file creation on UNIX shares | 18 comments | Create New Account
Click here to return to the 'Prevent .DS_Store file creation on UNIX shares' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Um...
Authored by: Numbski on Jan 13, '03 10:15:15AM

I presume that means that if you are mounting another machine running samba, you can veto that filename.

I don't think you can do this from Windows, unless there's a setting under Client for Microsoft Networks that allows you to do this kind of advanced configuration, I'll have to look later.



[ Reply to This | # ]
Sorry!
Authored by: robg on Jan 13, '03 10:24:10AM

That was my fault; I wrote "Windows" in the subject when I meant to type "UNIX." So this isn't related to Windows, but rather, UNIX.

Mea culpa ... it was a long weekend, and not necessarily in the good way! ;-)

-rob.



[ Reply to This | # ]
Tried it, didn't like the results
Authored by: jasonbergman on Jan 13, '03 11:39:00AM

I had this set for a while, but discovered that doing this was preventing me from copying whole folders over to my fileserver. What happened is that every time I tried to do it, I'd get a permissions error because it wouldn't let me copy .DS_store files.

I turned it off, and it worked just fine.



[ Reply to This | # ]
Tried it, didn't like the results
Authored by: al451 on Feb 03, '04 03:52:22PM
You need to also set

delete veto files = yes

in your smb.conf. That lets you delete folders that already contain "vetoed" files (those files will be deleted along with the folder).

[ Reply to This | # ]

veto config doesn't help for ._*
Authored by: magir on Nov 10, '04 11:23:14AM

The both veto lines in the smb.conf don't resolve the problem of ._*-files appearing. When I add the ._*/ clause it's not possible to create any files on the server (or at least to do that properly, the finder starts copying and fails).

So it solves the problem for .DS_STORE but not for ._* - sadly :-(.



[ Reply to This | # ]
.DS_Store and CVS
Authored by: officemonkey on Jan 13, '03 02:50:26PM

Does anyone have an idea of how to get CVS to globally ignore the .DS_Store files?

Speaking of which.. What the heck are the .DS_Store files anyway?

Can I nuke them with impunity?



[ Reply to This | # ]
.DS_Store and CVS
Authored by: bradrf on Jan 13, '03 02:58:06PM

You should be able to set the CVSIGNORE environment variable to contain .DS_Store.



[ Reply to This | # ]
.cvsignore it
Authored by: mingking on Jan 13, '03 08:50:08PM

You can put .DS_Store in a .cvsignore file in your home directory.



[ Reply to This | # ]
or use cvsignore in CVSROOT
Authored by: mingking on Jan 13, '03 09:01:03PM

If you have access to it you can also put .DS_Store in the cvsignore file in the CVSROOT project of a repository. That file is a global ignore for all users accessing that repository.

Oh, and .DS_Store files are used to store meta-data like icon positions within a window, custom icon settings, window size and location etc. You can delete them, but as soon as you open the window again with the Finder it will recreate a new one.



[ Reply to This | # ]
What about .DS_store on Compact Flash/SmartMedia?
Authored by: bluehz on Jan 14, '03 09:31:08AM

What about disabling the .DS_store files on CompactFlash/SmartMedia cards? I mount my CompactFlash card for my Nikon digital camera and my Visor PDA via a USB CompactFlash Reader and I am constantly getting .DS_Store files created on the mounted volume (CompactFlash Card) even without copying files, etc. These .DS_Store files can cause problems, especially on the PDA card.

Anyone know a method to prevent that?



[ Reply to This | # ]
And prevent ._ files on windows shares ?
Authored by: demental on Feb 26, '03 09:25:13AM

Hello, this tip would really be helpfull to me if it'd work on a windows shared partition.

Is there a way to prevent Mac from making ._myfile.ext when I copy or modify myfile.ext onto the windows partition ?



[ Reply to This | # ]
And prevent ._ files on windows shares ?
Authored by: knucklecheese on Feb 26, '03 12:01:55PM

This is a file system problem rather than a network protocol problem. Remember that HFS volumes contain multiple data-bearing forks. I believe that by transfering files between HFS and NTFS, FAT, FAT32, and UNIX file systems, the current technology strips the data fork from the mac file and places it in a seperate file in the single-branched pc or UNIX file system.

The reason?
When the file gets xferred back to the Mac, the extra files are necessary to re-combine both forks on the HFS file system in order for the "Classic" System and Apps to know what to do with them. If the PC simply discarded the additional data, you would have a huge problem on your hands when the older Mac Systems tried to use the resulting files. I understand that this is irrelevant to exclusive OSX users, but remember that most OSX installs still exist on HFS volumes and will behave the same way as classic files in this situation.

The solution?
I don't know of a solution right now, but there will be in the future. Once all aspects of the "Classic" operating system are extinct, Macs will be able to use alternative (UNIX) file systems, which will put an end to the problem.



[ Reply to This | # ]
And prevent ._ files on windows shares ?
Authored by: demental on Feb 27, '03 05:39:46AM

Do you mean that if I reinstall my Os on an UFS formatted disk (as I don't use classic anymore), this could work ?



[ Reply to This | # ]
And prevent ._ files on windows shares ?
Authored by: germsteel on Oct 10, '03 07:04:56PM

No just reinstall OS X without classic on HFS+ Stay away from UFS



[ Reply to This | # ]
And prevent ._ files on windows shares ?
Authored by: germsteel on Oct 10, '03 07:07:05PM

Actually I've done that and the ._ files are still created. So nix this theory it doesn't work.



[ Reply to This | # ]
And prevent ._ files on windows shares ?
Authored by: nodje on Nov 22, '03 02:53:26PM

I'm actually facing the same problem, but even a littlebit worst than that.
I can manually delete the .DS_Store file on a windows share (which is boring but still fine), but I've got some .DS_ file that are created and these files are simply unaccessible, undeletable ...
I've got a "Cannot read the source file or disc" from windows when trying to delete it, copy a folder that contain one .DS_. The windows partition get kind of corrupted!
I've tried everything but could'nt find any solution
Does anyone have an idea of where those .DS_ file come from?
Does anyone did already see them?
I can't find any reference on them on the web.

nodje



[ Reply to This | # ]
And prevent ._ files on windows shares ?
Authored by: Vocal Velocity on Oct 11, '04 04:10:22PM

Under Macintosh OSX .DS_Store holds the information which controls the way a folder will be opened; i.e., the shape and size of the window, the position of the window on the desktop and whether file, folder or icon view has been selected. If you were to delete the .DS_Store the folder would revert to the system default next time it is opened and a new blank .DS_Store would appear (invisibly).
I wanted to post this here for a clear understanding what the .DS_Store file is and help everyone understand that it probably will not be going away anytime soon.



[ Reply to This | # ]
Prevent .DS_Store file creation on UNIX shares
Authored by: taxi on Jan 19, '07 10:12:02PM

A better option than a veto might be a hide - that way the files are still created, but you don't see them.

As someone else noted, if you veto ._* files, then you can't copy using the Finder anymore.



[ Reply to This | # ]