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

Burn CDs without the invisible .DS_Store files Desktop
I often have to burn CDs for people using Windows machines. After sending out CDs, I would often get a phone call or e-mail asking me what the .ds_store file is. On unix, a file beginning with a dot (.) is invisible, but not on Windows, so the file that contains all the Finder's formatting information comes up as a regular file for them.

I now remove those files before burning by running the following unix command on the mounted un-burnt disk or in the folder I'm going to create a master from:
 % find . | grep .DS_Store | xargs rm
Make sure that the disk or folder in question is NOT open in the Finder, and do not open them after running this. Also be aware that you will lose any window display state information, so only run this on CDs that are destined for use on Windows and backup the folder before running if you need to preserve the Mac finder properties.
    •    
  • Currently 3.33 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (3 votes cast)
 
[17,316 views]  

Burn CDs without the invisible .DS_Store files | 16 comments | Create New Account
Click here to return to the 'Burn CDs without the invisible .DS_Store files' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
no need to grep
Authored by: mkhaw on Jan 30, '03 10:42:53AM

The "grep" in the pipeline can be eliminated:

find . -name .DS_Store -print | xargs rm

you could also use the following to avoid a pipe,

find . -name .DS_Store -exec rm

but it's likely to be slower as it runs a new instance of "rm" for each file found. Generally I find that "find ... -print | xargs ..." is more efficient than the equivalent "find ... -exec ..."



[ Reply to This | # ]
no need to grep
Authored by: wmscyclone on Jan 30, '03 11:43:59AM

If you're in the default tcsh, just use

find . -name .DS_Store -delete

and it will delete all the .DS_Store files found in that directory and all of it's subdirectories. If you're really worried about it first run

find . -name .DS_Store -print

to get a list of all the .DS_Store files, then use the -delete option to nuke them all.



[ Reply to This | # ]
Or alternatively...
Authored by: gidds on Jan 30, '03 10:53:22AM
If you're using zsh instead of bash (which I think everyone should), then you can simply use
rm **/.DS_Store
to do all that in one go.

[ Reply to This | # ]
Cleaner way
Authored by: dannyboy on Jan 30, '03 11:05:12AM
use: find . -name .DS_Store -print -exec /bin/rm {} ; ... will print out each file that it removes. Some versions of xargs have problems with large number os arguments. You can also add a -i (interactive / prompt before deleting) or -f (force) argument to rm for both methods. dan

[ Reply to This | # ]
Ouch... don't do that
Authored by: merlyn on Jan 30, '03 11:16:05AM
Because OSX filenames commonly contain whitespace, doing anything with find and xargs requires the NUL-delimited mode:
find ... -print0 | xargs -0 ...


This is the same mistake that Apple made for the iTunes 1.1 update that deleted entire volumes if they were named with a space-included name.


Do not be as dumb as Apple here.

[ Reply to This | # ]

please, please, please...
Authored by: gvitale on Jan 30, '03 11:31:17AM

Could you explain that in more details?
It looks like an important point for correct find usage...
Thanks in advance.
gaetano



[ Reply to This | # ]
why using -0 and -print0 matters
Authored by: merlyn on Jan 30, '03 01:17:57PM
By default, xargs takes any whitespace in its input to delimit between entries. This is fine for traditional typical Unix filenames, but has always been a problem for security-minded folks who know that filenames can contain arbitrary whitespace (spaces, tabs, newlines).


In fairly modern versions of xargs (including the version shipped with OSX), the -0 switch can be added, which overrides the delimiter to be strictly and only the ASCII NUL byte (which cannot ever appear within a filename, because all Unix system calls are NUL-terminated strings). Now, this won't work with traditional find ... -print, but most modern find commands have also been updated to include -print0, which puts a NUL byte between entries -- not a newline!


So, when you use them together, you get a nice handoff solution for what was formerly a security nightmare. As the good folks at Apple found out for the iTunes update... whitespace matters!

[ Reply to This | # ]

Using find with xargs caveat
Authored by: sophistry on Jan 30, '03 11:58:18AM

From the find man pages:

<snip>
-X The -X option is a modification to permit find to be safely used
in conjunction with xargs(1). If a file name contains any of the
delimiting characters used by xargs(1), a diagnostic message is
displayed on standard error, and the file is skipped. The delim-
iting characters include single (`` ' '') and double (`` " '')
quotes, backslash (``\''), space, tab and newline characters.
<snip>



[ Reply to This | # ]
Using find with xargs caveat
Authored by: merlyn on Jan 30, '03 01:20:00PM
Right, but see my other answer in this thread. You want:
find .... -print0 | xargs -0 ....
Not -X.

[ Reply to This | # ]
The Easiest
Authored by: filburt on Jan 30, '03 12:03:53PM

find . -name .DS_Store -delete



[ Reply to This | # ]
Hey ROXIO!!! (and Apple) help us out!
Authored by: ScooterComputer on Jan 30, '03 12:22:47PM

I still can't figure out why both Roxio and Apple haven't "simplified" this process with Toast and OS X's Disc Recording framework. I mean, it isn't as though this is something NOBODY does!

I'd really prefer it if Apple would 1) allow for a Finder flag that one could set whereby the Finder would not write the damn things to a volume in the first place and 2) create a utility (perhaps in Get Info or Disk First Aid) for them to be removed en masse from a volume. This has been discussed before from the standpoint of OS X treaded not-so-lightly on Windows shares, something that HAS raised the ire of sysadmins.



[ Reply to This | # ]
Apple's DiscRecording already does this
Authored by: arwyn on Jan 30, '03 12:40:48PM

This hint is unnecessary when using Apple's DiscRecording software post 10.2.

The .DS_Store (and many other mac-only metadata) files will be stripped from the crossplatform ISO/Joilet images. These files will still show up for the HFS+ side of hybrid images, so mac users will get them but other users on other platforms won't.



[ Reply to This | # ]
Apple's DiscRecording already does this
Authored by: TTop on Jan 30, '03 06:58:01PM

Sorry for being ignorant here -- is DiscRecording included with Jaguar? Where can I find it?



[ Reply to This | # ]
The EASIEST way!!! (I mean it)
Authored by: aqsalter on Jan 30, '03 05:50:31PM

The easiest way to get rid of all the "." files on Windows shares/CDROMs is to download "Clean SMB Mess" from Versiontracker.

It is a small drag-n-drop app which cleans any volume you drop on it (including CD-ROMs)



[ Reply to This | # ]
A follow-up...
Authored by: robg on Jun 05, '03 09:38:04AM
From the original Anon poster comes this follow-up:
There was one problem with this hint: invisible files in a directory path with a space in it were not deleted. Here is a revised version that will properly handle directories with spaces in them (although it doesn't handle double-quotes in directory paths, but how often do people do that?)

In the terminal, navigate to the root of the directory to be burnt or imaged and type:
find . | grep 'DS_Store$' | awk '{printf("\"%s\"\n", %0)}' | xargs rm
Again, as before, do not open the directory in the Finder after doing this until you've created the disk image or burnt the disk, and don't run this command on your original directory if there is any Finder layout information that you want to keep.


[ Reply to This | # ]
Or, you could use "Chop"...
Authored by: zenox on Nov 29, '03 03:54:26AM
...hold down simultaneously the Command, Option and Control keys while you drag & drop a folder onto the Chop application icon: it will delete all the invisible ".DS_Store" files enclosed in that particular folder and its subfolders. You can find Chop here: http://zenonez.com/chop

[ Reply to This | # ]