From Newsgroup: comp.sys.mac.system

I want to remove every ".DS_Store" file from my boot partition _and_
all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

So far, I tried the following, which failed to work.

From Terminal: (working as root user)

cd /

rm -rf .DS_Store



For some reason, I can't get rm to recursively decend though all my directories and remove the ,DS_Store files in all of my 3 partitions.

I thought the -r option in the command would do the trick, but no joy.

Mark-
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2006-04-12, Mark Conrad <NoMailAccepted@invalid.com> wrote:

I want to remove every ".DS_Store" file from my boot partition _and_
all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

So far, I tried the following, which failed to work.

From Terminal: (working as root user)

cd /

rm -rf .DS_Store

For some reason, I can't get rm to recursively decend though all my directories and remove the ,DS_Store files in all of my 3 partitions.

I thought the -r option in the command would do the trick, but no joy.

Mark-

rm don't find the files you want to erase.. the -r will erase a
directory recursively.. but that will not find all the occurence of the specified files...

To acheive what you want, you should use something like

sudo find / -name ".DS_Store" -exec rm -f {} \;

It may take a while depending how big and how full is your hardrive..
and how much drives you have mounted on /Volumes.

Note: be carefull to don't let "find" match files that you don't
want to delete.. it's don't go to the trash when you use "rm"...
espescially if you use wilcard ("*") with the "-name" argument.

--
Martin
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2006-04-12, Mark Conrad <NoMailAccepted@invalid.com> wrote:

I want to remove every ".DS_Store" file from my boot partition _and_
all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

So far, I tried the following, which failed to work.

From Terminal: (working as root user)

cd /

rm -rf .DS_Store

That would remove .DS_Store and all subdirectories and files
in it - but it is not a directory so the -r option has no effect.
find(1) is your friend:

find / -type f -name .DS_Store -delete

It might take a while. Also, you might want to run it without the
delete option first, just out of interest to see how many there
are. The "-type f" restricts it to deleting ordinary files - not
necessary unless you have created a directory called .DS_Store
somewhere with important files in.

Ian

--
Ian Gregory
http://www.zenatode.org.uk/ian/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <120420060909413515%NoMailAccepted@invalid.com>, Mark Conrad <NoMailAccepted@invalid.com> wrote:

I want to remove every ".DS_Store" file from my boot partition _and_
all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

So far, I tried the following, which failed to work.

From Terminal: (working as root user)

cd /

rm -rf .DS_Store

For some reason, I can't get rm to recursively decend though all my directories and remove the ,DS_Store files in all of my 3 partitions.

I thought the -r option in the command would do the trick, but no joy.

Mark-

Never mind, answered my own question by doing some more Googling.

Hate what I found though, because I still wish the simple way of using
"rm" would have worked.

To completely remove (temporarily) all .DS_Store files:

(working as root user)

cd /

find / -name ".DS_Store" -depth -exec rm {} \;


It works, but I do not understand a few things, specifically why {} is
used, and what is the purpose of \; at the end.

Perhaps the "man" page will throw some light on these issues, but I
doubt it, as the man pages are often impossible to understand.

Mark-
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <120420060909413515%NoMailAccepted@invalid.com>,
Mark Conrad <NoMailAccepted@invalid.com> wrote:

I want to remove every ".DS_Store" file from my boot partition _and_
all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

So far, I tried the following, which failed to work.

From Terminal: (working as root user)

cd /

rm -rf .DS_Store

The -r flag will recursively descend into any *arguments* to rm(1) that
happen to be directories; .DS_Store is a normal file, so it doesn't
descend into it (which is clearly impossible). You might want to read
the man page for rm(1).

What you want to do is search for files named ".DS_Store" and perform a particular action on them (delete them). You'll find the following
command much more useful:

$ find / -type f -name .DS_Store -exec rm {} \;

Since you're doing this from the root directory and will be stepping
through directories which you probably don't have write permission for,
you'll probably want to prefix this command with "sudo".

A couple of caveats:

1. Back up your system first before you go making such changes to your
filesystem(s).

2. Be aware that after you delete the .DS_Store files, you will lose
your window size and icon arrangement for EVERY SINGLE FOLDER ON
YOUR HARD DRIVE that isn't presently in an open window in the
Finder. Furthermore, if you had any Spotlight comments (a.k.a.
Finder comments) associated with any files whatsoever, they'll also
be blown away. That's what .DS_Store files are used for.

3. The next time you open a folder, or if you close any existing open
folders in the Finder that were open when you performed this action
in Terminal.app, .DS_Store files will be recreated for these
folders. You're not going to get rid of these files unless you stop
using the Finder.

--
Gregory Pratt gp@panix.com
East Rutherford, NJ, USA http://www.panix.com/~gp/
"The only good spammer is a dead spammer."
PGP Key Fingerprint: DC60 FCDE 91E2 3D41 91A3 45DB B474 3D3A 3621 AAFE
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2006-04-12, Mark Conrad <NoMailAccepted@invalid.com> wrote:

Never mind, answered my own question by doing some more Googling.

Hate what I found though, because I still wish the simple way of using
"rm" would have worked.

To completely remove (temporarily) all .DS_Store files:

(working as root user)

cd /

find / -name ".DS_Store" -depth -exec rm {} \;

This is a variant on what I suggested. I don't see why they
use -depth, and it is an unneccessary use of -exec (I would
use -delete instead). There is no need for the initial "cd /"
because "/" is specified as the root in the find command.

It works, but I do not understand a few things, specifically why {} is
used, and what is the purpose of \; at the end.

These are both explained in the man page, look for a description
of the -exec option.

Basically {} is replaced by the current pathname. The syntax
for -exec requires that it is terminated by a semicolon, and
the backslash is there to "escape" the semicolon (so that it
is not interpreted by the shell).

Ian

--
Ian Gregory
http://www.zenatode.org.uk/ian/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <120420060939329888%NoMailAccepted@invalid.com>,
Mark Conrad <NoMailAccepted@invalid.com> wrote:

To completely remove (temporarily) all .DS_Store files:

(working as root user)

cd /

find / -name ".DS_Store" -depth -exec rm {} \;

It works, but I do not understand a few things, specifically why {} is
used, and what is the purpose of \; at the end.

Any time find(1) locates a file that matches all of your criteria, it
will execute the command specified with "-exec", replacing "{}" with the pathname of that file. The semicolon terminates this command; it must
be escaped (prefixed with a backslash) to prevent the shell from
interpreting it at the time you enter it.

In this case, the "-depth" option is unnecessary. This causes the
deepest directories to be acted upon first, rather than acting upon
them in the order in which they are encountered. This is most useful
when acting on directories, since many operations (such as deleting directories) need to be done this way.

Perhaps the "man" page will throw some light on these issues, but I
doubt it, as the man pages are often impossible to understand.

Well-written man pages are easy to read, once you know how. But they
are daunting for beginners -- there is a skill involved that really only improves with practice. And there are, of course, some badly-written
manual pages out there, too.

--
Gregory Pratt gp@panix.com
East Rutherford, NJ, USA http://www.panix.com/~gp/
"The only good spammer is a dead spammer."
PGP Key Fingerprint: DC60 FCDE 91E2 3D41 91A3 45DB B474 3D3A 3621 AAFE
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

Mark Conrad wrote
(in article <120420060939329888%NoMailAccepted@invalid.com>):

In article <120420060909413515%NoMailAccepted@invalid.com>, Mark Conrad <NoMailAccepted@invalid.com> wrote:

I want to remove every ".DS_Store" file from my boot partition _and_
all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

So far, I tried the following, which failed to work.

From Terminal: (working as root user)

cd /

rm -rf .DS_Store



For some reason, I can't get rm to recursively decend though all my
directories and remove the ,DS_Store files in all of my 3 partitions.

I thought the -r option in the command would do the trick, but no joy.

Mark-

Never mind, answered my own question by doing some more Googling.

Hate what I found though, because I still wish the simple way of using
"rm" would have worked.

To completely remove (temporarily) all .DS_Store files:

(working as root user)

cd /

find / -name ".DS_Store" -depth -exec rm {} \;

It works, but I do not understand a few things, specifically why {} is
used, and what is the purpose of \; at the end.

Perhaps the "man" page will throw some light on these issues, but I
doubt it, as the man pages are often impossible to understand.

If you want to really understand this stuff, you need to find
either in depth tutorial on UNIX shell scripting, or pick up a
good used UNIX shell scripting book in a book store somewhere.
That stuff is old as hell, hasn't changed in many years, so just
about any reference should help you.


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw





--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <0001HW.C0629CC001E525ABF0386530@news.verizon.net>, Randy
Howard <randyhoward@FOOverizonBAR.net> wrote:

If you want to really understand this stuff, you need to find
either in depth tutorial on UNIX shell scripting, or pick up a
good used UNIX shell scripting book in a book store somewhere.
That stuff is old as hell, hasn't changed in many years, so just
about any reference should help you.

Google "Mark Congrad" and you'll discover that he doesn't want to learn
it, or is incapable of learning it (to give him the benefit of some
doubt). Suggesting he read man pages or a book has been done to death
and he has yet to make the effort.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <4a4of2FrksgpU1@individual.net>,
Ian Gregory <foo@bar.invalid> wrote:

On 2006-04-12, Mark Conrad <NoMailAccepted@invalid.com> wrote:

I want to remove every ".DS_Store" file from my boot partition _and_ all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

So far, I tried the following, which failed to work.

From Terminal: (working as root user)

cd /

rm -rf .DS_Store

That would remove .DS_Store and all subdirectories and files
in it - but it is not a directory so the -r option has no effect.
find(1) is your friend:

find / -type f -name .DS_Store -delete

This works:
find /. -iname ".DS_Store" | xargs rm -v

and also

find /. -iname "._*" | xargs rm -v

to remove all the ._ files that also infest directories.

Both list every instance of the deleted files. If you just want to look
for them, quit before you get the pipe operator.

It might take a while.

One or two seconds, typically. But then I'm not trying to delete every instance of the files on my system, just those that I'll be moving over
to, say, a Solaris system for distribution at work.

Also, you might want to run it without the
delete option first, just out of interest to see how many there
are. The "-type f" restricts it to deleting ordinary files - not
necessary unless you have created a directory called .DS_Store
somewhere with important files in.

Ian

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <120420061229593647%dave@N_O_T_T_H_I_Sbalderstone.ca>, Dave Balderstone <dave@N_O_T_T_H_I_Sbalderstone.ca> wrote:

Google "Mark Congrad"

Typo. s/b "Mark Conrad"
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On Wed, 12 Apr 2006 11:09:16 -0500, Mark Conrad wrote
(in article <120420060909413515%NoMailAccepted@invalid.com>):

I want to remove every ".DS_Store" file from my boot partition _and_
all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

So far, I tried the following, which failed to work.

From Terminal: (working as root user)

cd /

rm -rf .DS_Store

For some reason, I can't get rm to recursively decend though all my directories and remove the ,DS_Store files in all of my 3 partitions.

I thought the -r option in the command would do the trick, but no joy.

Mark-

Why do you want to remove them?

--

Tim
lance_1012@hotmail.com

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <120420060909413515%NoMailAccepted@invalid.com>,
Mark Conrad <NoMailAccepted@invalid.com> wrote:

I want to remove every ".DS_Store" file from my boot partition _and_
all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

How about a program in something quick like RealBasic. Start at the top
level, maintain a stack of folders, and nuke everything with the
filename .DS_Store. Running from root, of course.

I wrote a similar program that searches my MP3 folders and creates
random music discs for the car.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <x-75D395.19100912042006@news.giganews.com>,
Quiet Desperation <x@x.com> wrote:

In article <120420060909413515%NoMailAccepted@invalid.com>,
Mark Conrad <NoMailAccepted@invalid.com> wrote:

I want to remove every ".DS_Store" file from my boot partition _and_
all the other partitions of my internal drive. (10.4.6 with 3
partitions total, one bootable)

Even remove all .DS_Store files in system directories.

How about a program in something quick like RealBasic. Start at the top >level, maintain a stack of folders, and nuke everything with the
filename .DS_Store. Running from root, of course.

I wrote a similar program that searches my MP3 folders and creates
random music discs for the car.

For most people, if they wanted to do it the Unix way, I'd suggest
something like

sudo find / -name ".DS_Store" -print0 | xargs -0 rm -f

For Mark, I'd suggest something like

sudo find / -exec rm -f "{}" \; -name ".DS_Store"

--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <120420060939329888%NoMailAccepted@invalid.com>,
Mark Conrad <NoMailAccepted@invalid.com> wrote:

find / -name ".DS_Store" -depth -exec rm {} \;

It works, but I do not understand a few things, specifically why {} is
used, and what is the purpose of \; at the end.

{} gets replaced with the name of each file that find found.
\; tells the find command that the command to execute is finished -- you
can put other find options after that.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

Entity Matthew Russotto uttered this profundity:

For Mark, I'd suggest something like

sudo find / -exec rm -f "{}" \; -name ".DS_Store"

I tried that and now my Mac won't boot. What's wrong?

;=)

-- Gnarlie

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <0001HW.C0629CC001E525ABF0386530@news.verizon.net>, Randy
Howard <randyhoward@FOOverizonBAR.net> wrote:

find / -name ".DS_Store" -depth -exec rm {} \;

It works, but I do not understand a few things, specifically why {} is used, and what is the purpose of \; at the end.

Perhaps the "man" page will throw some light on these issues, but I
doubt it, as the man pages are often impossible to understand.

If you want to really understand this stuff, you need to find
either in depth tutorial on UNIX shell scripting, or pick up a
good used UNIX shell scripting book in a book store somewhere.
That stuff is old as hell, hasn't changed in many years, so just
about any reference should help you.

Thanks, I will grab a book at random, such as:

Mastering Unix Shell Scripting

by author Randal K. Michael

I want thank the following people, who responded with much needed
advice on this thread subject. Without your help, with _only_ the
man pages and Unix books, it would not be possible for me to learn a
lot of this Unix stuff.

Martin Gagnon
Ian Gregory
Steve Hix
Greg Pratt
Barry Margolin
Tim Lance
"Quiet Desperation"
Matthew Russotto

...and of course yourself, Randy Howard.

As usual, I will save all the helpful comments in this thread for
future reference, because my memory is not very good.

Mark-
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <S7Kdnbj1QpGIOaDZRVn-vg@giganews.com>, Tim Lance <lance_1012@hotmail.com> wrote:

Why do you want to remove them?

Strictly curiousity, especially because some Mac users cautioned me
that all sorts of dire things would happen if I removed (temporarily)
all of the .DS_Store files.

I am aware of most of the minor things that will happen, however I
firmly believe that no major disaster will occur.

Mark-
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On Thu, 13 Apr 2006 00:58:22 -0500, Mark Conrad wrote
(in article <120420062258372062%NoMailAccepted@invalid.com>):

In article <S7Kdnbj1QpGIOaDZRVn-vg@giganews.com>, Tim Lance <lance_1012@hotmail.com> wrote:

Why do you want to remove them?

Strictly curiousity, especially because some Mac users cautioned me
that all sorts of dire things would happen if I removed (temporarily)
all of the .DS_Store files.

I am aware of most of the minor things that will happen, however I
firmly believe that no major disaster will occur.

Mark-

Thanks for responding. Many think deleting them clears up mysterious woes. IIRC, Onyx and many similar apps have deleting them as a built-in option.

--

Tim
lance_1012@hotmail.com

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <OP2dnXMnvZOm_KPZRVn-sw@giganews.com>, Tim Lance <lance_1012@hotmail.com> wrote:

Thanks for responding. Many think deleting them clears up mysterious woes. IIRC, Onyx and many similar apps have deleting them as a built-in option.

Somewhere in all my Googling, I ran into a series of posts that claimed
the main reason that Apple included one .DS_Store files with every
directory (folder) was for backward compatability with Classic, i.e.
older OS-9 files, applications, and such.

In my Pismo with OS 10.4.6 there are 25,725 directories (folders), so
that means there are roughly the same number of .DS_Store files, one in
each directory.

Being the newest Intel based Macs no longer run Classic, it now appears
there is no reason to hang onto those .DS_Store files, so I would not
be surprised to see Apple abandon all those many thousands of .DS_Store
files, one .DS_Store file per directory, in future versions of their OS
- - - and replace them with some centralized method of doing the minor
things that are now being done by thousands of scattered .DS_Store
files.

Those minor thing are -

Keeping Track of:
1) icon locations in window
2) window size
3) Spotlight "comments" associated with a file
4) any menu action that causes the locations of
icons in a window to "jump" to a slightly
different location - - - for example, clicking
on the "Clean Up" entry in the "View" menu

...and likely a few other minor things

Whenever you delete a .DS_Store file, all the above things return to
default values, i.e. the icons jump to default locations in a window,
the window size itself jumps to a default size, and Spotlight
"comments" revert to blank (no comments).

Also, _no_ "new" .DS_Store file gets created, not even if you
restart your Mac.

Not even creating a new file will cause a new .DS_Store file to be
created, provided you do not move any icons in the window, or rezize
the window.

However, _if_ you move any icons, or change the window size, or "automatically" re-arrange all the icons in the window, _then_ a
.DS_Store file gets created again.

Mark-
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2006-04-14, Mark Conrad <NoMailAccepted@invalid.com> wrote:

In article <OP2dnXMnvZOm_KPZRVn-sw@giganews.com>, Tim Lance
<lance_1012@hotmail.com> wrote:

Thanks for responding. Many think deleting them clears up mysterious woes. >> IIRC, Onyx and many similar apps have deleting them as a built-in option.

Somewhere in all my Googling, I ran into a series of posts that claimed
the main reason that Apple included one .DS_Store files with every
directory (folder) was for backward compatability with Classic, i.e.
older OS-9 files, applications, and such.

How many .DS_Store files did you find on your system?

As I understand it, after doing a clean install of Mac OS X, the
filesystem will contain few if any .DS_Store files. The following
URL describes "Mac OS X Hidden Files & Directories":

http://www.westwind.com/reference/OS-X/invisibles.html

The entry for .DS_Store reads:

This file in created by the Finder to keep track of folder view
options, icon positions, and other visual information about folders.
A separate .DS_Store file is created in each directory to store
information about that directory, so you'll find them appearing
all over the directory tree, in pretty much every folder you've
visited with the OS X Finder.

No mention of Classic.

Ian

--
Ian Gregory
http://www.zenatode.org.uk/ian/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <130420062124042941%NoMailAccepted@invalid.com>,
Mark Conrad <NoMailAccepted@invalid.com> wrote:

In article <OP2dnXMnvZOm_KPZRVn-sw@giganews.com>, Tim Lance <lance_1012@hotmail.com> wrote:

Thanks for responding. Many think deleting them clears up mysterious woes. IIRC, Onyx and many similar apps have deleting them as a built-in option.

Somewhere in all my Googling, I ran into a series of posts that claimed
the main reason that Apple included one .DS_Store files with every
directory (folder) was for backward compatability with Classic, i.e.
older OS-9 files, applications, and such.

In my Pismo with OS 10.4.6 there are 25,725 directories (folders), so
that means there are roughly the same number of .DS_Store files, one in
each directory.

My iBook only has 1389 .DS_Store files out of 109239 directories
(1.27 percent)

Most of the directories on the system are System, Library, caches,
etc... where either the Finder does not see, or you as a user do
not navigate to with the Finder. Hence no .DS_Store files

By the way, I found out how many .DS_Store files I had by using

locate .DS_Store | wc

of course I also have root run the nightly
/usr/libexec/locate.updatedb
job that updates the locate database, but that is a totally
different subject.

Being the newest Intel based Macs no longer run Classic, it now appears
there is no reason to hang onto those .DS_Store files, so I would not
be surprised to see Apple abandon all those many thousands of .DS_Store files, one .DS_Store file per directory, in future versions of their OS
- - - and replace them with some centralized method of doing the minor
things that are now being done by thousands of scattered .DS_Store
files.

I disagree. Mac OS 9 (and earlier) never used .DS_Store files, so
they are a MacOSX invention (or maybe a NeXT invention, but
definitely not Classic or Mac OS 9 or earlier). Mac OS 9 (or
earlier) used a combination of a central per file system desktop
database, and per file metadata. MacOSX could have just used the
existing desktop databases and per file metadata as a file is a
file, and HFS+ was the file system used by Mac OS 9 (or earlier).
MacOSX choose not to. That tells me it has nothing to do with
compatibility.

An advantage of .DS_Store files along with the ._filename files of
Apple Double format, is that MacOSX can store files on non-HFS+
file systems and still present a MacOSX consistent view. This
would include CDs and DVDs in non-HFS+ format, USB Memory Stick
drives, Flash Memory Cards from Cameras and PDAs, SMB/CIFS Windows
network mounted file systems, NFS UNIX style file systems, etc..

Another advantage is that a central database can get corrupted,
and when it does, you loose the information for the entire file
system. if you corrupt one .DS_Store file, then only one
directory looses its information.

An advantage to storing file position, file color, file icon size
etc... information in .DS_Store file vs storing that information
as per file metadata is that when the finder opens a directory for
display it only needs to read one .DS_Store and the file names
from the directory to know how to layout the Folder window. If
each file's metadata is stored separately, then the Finder has to
read the list of file name, then perform an open on each file
being displayed before it can display the file. This is a lot of
extra overhead, especially if there are a lot of files in the
directory. This is how Mac OS 9 (and earlier) had to work. And
while the HFS and HFS+ file systems have aids to make this less
painful, it does not help foreign file systems that MacOSX deals
with much more frequently in this interconnected world.

So while Apple may or may not change from using .DS_Store (and
._filename Apple Double format for non-HFS+ file systems), I do
not think this will have anything to do with Classic going away,
and as such I do not think it will go away anytime soon.

Those minor thing are -

Keeping Track of:
1) icon locations in window
2) window size
3) Spotlight "comments" associated with a file
4) any menu action that causes the locations of
icons in a window to "jump" to a slightly
different location - - - for example, clicking
on the "Clean Up" entry in the "View" menu

...and likely a few other minor things

You may think of them as minor, but for the Apple GUI experience,
they are kind-of essential. Or at least the information is
essential for the experience, not where they are stored.

Whenever you delete a .DS_Store file, all the above things return to
default values, i.e. the icons jump to default locations in a window,
the window size itself jumps to a default size, and Spotlight
"comments" revert to blank (no comments).

Also, _no_ "new" .DS_Store file gets created, not even if you
restart your Mac.

Not even creating a new file will cause a new .DS_Store file to be
created, provided you do not move any icons in the window, or rezize
the window.

However, _if_ you move any icons, or change the window size, or "automatically" re-arrange all the icons in the window, _then_ a
.DS_Store file gets created again.

So you just proved my point. There are not 1000's of .DS_Store
files on the file system. Just a thousand or so. Or just over 1%
of the directories contain .DS_Store files.

On my system all the .DS_Store files take up a total of 13MB. I
have more than that tied up in some graphics files or a long .mp3
music file. And since I have a 100GB disk (93 real GB), that is
0.01% of my disk storage). And if you disk is as small as 6GB
then this would be only 0.2%. This is noise and not a major
concern for me or most people.

I found out how much space my .DS_Store files were using via:
sudo find / -name ".DS_Store" -print0 |\
xargs -0 ls -s |\
awk '{size += $1} END{print size}'

But if you want to delete them, have fun.

Bob Harris

Mark-

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <nospam.News.Bob-533D6D.21124314042006@news.verizon.net>,
Bob Harris <nospam.News.Bob@remove.Smith-Harris.us> wrote:

In my Pismo with OS 10.4.6 there are 25,725 directories (folders), so
that means there are roughly the same number of .DS_Store files, one in each directory.

My iBook only has 1389 .DS_Store files out of 109239 directories
(1.27 percent)

Most of the directories on the system are System, Library, caches,
etc... where either the Finder does not see, or you as a user do
not navigate to with the Finder. Hence no .DS_Store files

Thanks for straightening me out on that.

This is why these NGs are so great, any mis-conceptions get cleared up
by others who know more about the subject.

By the way, I found out how many .DS_Store files I had by using

locate .DS_Store | wc

Great tip, I will add that to my limited Unix arsenal, thanks.

of course I also have root run the nightly
/usr/libexec/locate.updatedb
job that updates the locate database, but that is a totally
different subject.

Sounds useful, but I thought that OS X had some mechanism that
periodically updated the 'locate' database?

Of course, if the auto' update feature does not work often enough, it
could be a bit useless whenever a 'locate' search was done.

Being the newest Intel based Macs no longer run Classic, it now appears there is no reason to hang onto those .DS_Store files, so I would not
be surprised to see Apple abandon all those many thousands of .DS_Store files, one .DS_Store file per directory, in future versions of their OS
- - - and replace them with some centralized method of doing the minor things that are now being done by thousands of scattered .DS_Store
files.

I disagree. Mac OS 9 (and earlier) never used .DS_Store files, so
they are a MacOSX invention (or maybe a NeXT invention, but
definitely not Classic or Mac OS 9 or earlier).

Hokay, that's what I get for listening to gossip on the net.<g>

Whenever you delete a .DS_Store file, all the above things return to default values, i.e. the icons jump to default locations in a window,
the window size itself jumps to a default size, and Spotlight
"comments" revert to blank (no comments).

Also, _no_ "new" .DS_Store file gets created, not even if you
restart your Mac.

Not even creating a new file will cause a new .DS_Store file to be
created, provided you do not move any icons in the window, or rezize
the window.

However, _if_ you move any icons, or change the window size, or "automatically" re-arrange all the icons in the window, _then_ a .DS_Store file gets created again.

So you just proved my point. There are not 1000's of .DS_Store
files on the file system. Just a thousand or so. Or just over 1%
of the directories contain .DS_Store files.

On my system all the .DS_Store files take up a total of 13MB. I
have more than that tied up in some graphics files or a long .mp3
music file. And since I have a 100GB disk (93 real GB), that is
0.01% of my disk storage). And if you disk is as small as 6GB
then this would be only 0.2%. This is noise and not a major
concern for me or most people.

I found out how much space my .DS_Store files were using via:
sudo find / -name ".DS_Store" -print0 |\
xargs -0 ls -s |\
awk '{size += $1} END{print size}'

Thanks very much for all that info', especially the last part about
finding how much disk space is being used for all the DS files.

I have a book about Terminal scripting on order, hope I can understand
the Unix stuff therein, when it arrives:
Mastering Unix Shell Scripting
by author Randal K. Michael

I find your posting style very refreshing, because most Unix pros here
merely give vague broad hints on Unixy stuff, then expect me to do
_all_ the hard work of digging out the essential details.

You manage to work those details directly into your posts, which has
the benefit of actually showing us non-Unix types that Unix is good for
the practical everyday operation of a Mac.

If you every decide to write a Unix book, let me know so I can be the
first one standing in line for the book.


About deleting .DS_Store files
*********************

But if you want to delete them, have fun.

Naw, as I stated near the start of this thread, my interest in the DS
files is just a matter of curiousity.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <4aajutFsbjs0U1@individual.net>, Ian Gregory
<foo@bar.invalid> wrote:

How many .DS_Store files did you find on your system?

Actually, I do not know how many on a "well used" OSX of mine.

A determined Unix user, as an exercise, could likely create as many
.DS_Store files as there are directories, by creating a script that
would re-arrange the icons in every directory.

...grabbing hold of OSX's View options from Terminal, for example.

Specifically the "Arrange By" selections in the View menu.

Unfortunately, I recently deleted _all_ my .DS_Store files before I
knew how to count how many of them there were.

Bob Harris sez a bit more that one percent of his files were .DS_Store

As I posted to Bob, I was wrong in my assumption that there were almost
as many DS files as there were directories.

http://www.westwind.com/reference/OS-X/invisibles.html

The entry for .DS_Store reads:

This file in created by the Finder to keep track of folder view
options, icon positions, and other visual information about folders.
A separate .DS_Store file is created in each directory to store
information about that directory, so you'll find them appearing
all over the directory tree, in pretty much every folder you've
visited with the OS X Finder.

Yes, even that is a bit misleading by its wording stating that a
seperate DS file "is created" in every directory.<g>

You are correct in that few if any DS files will be created on a fresh
install of OS X.

- assuming root user, working with boot partition -
One can remove all .DS_Store files thus:

find / -name ".DS_Store" -exec rm {} \;

I did it just out of curiousity.

...and if they are careful to avoid doing anything such as moving an
icon, re-sizing a window, etc., etc. ...then no .DS_Store files
will be "created".

I better state a disclaimer here that I am not advocating removing
.DS_Store files, to avoid the usual rash of dingbats who try to read
things like that into posts like this.

Counting the total number of .DS_Store files worked well for me.
(working as root user)

I first updated the 'locate' database:

/usr/libexec/locate.updatedb

That took perhaps 20 seconds on my old powerbook.

Then I counted the total number of DS files.

locate .DS_Store | wc

That yielded a 3 column printout thus:

0 0 0

...the left column being the total count of all .DS_Store files.

Zero files because I had previously removed them all.

I do not know what columns 2 and 3 signify in that printout, because as
usual the man page for wc is inscrutable, and no amount of
experimentation on my part could ferret out any practical uses for
columns 2 and 3 in the Terminal printout.

No mention of Classic.

Yep, the net gossip failed me, Classic is not the reason; Bob's
analysis of the reasons makes more sense.

Mark-
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

On 2006-04-15, Mark Conrad <NoMailAccepted@invalid.com> wrote:

locate .DS_Store | wc

That yielded a 3 column printout thus:

0 0 0

...the left column being the total count of all .DS_Store files.

Column 1 is the number of lines in the output of the locate command.

Given what the locate command does this would be expected to be
equal to the number of .DS_Store files.

I do not know what columns 2 and 3 signify in that printout, because as
usual the man page for wc is inscrutable, and no amount of
experimentation on my part could ferret out any practical uses for
columns 2 and 3 in the Terminal printout.

Column 2 is the number of words in the output of the locate command.
Column 3 is the number of bytes in the output of the locate command.

This is explained clearly in the man page, vis:

The wc utility displays the number of lines, words, and bytes
contained in each input file (or standard input, by default)
to the standard out-put.

Since the number of words and bytes in the output of the locate
command is not relevent you might just want to print the number
of lines:

dune$ locate .DS_Store | wc
32 65 1560
dune$ locate .DS_Store | wc -l
32

Ian

--
Ian Gregory
http://www.zenatode.org.uk/ian/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <140420062300433698%NoMailAccepted@invalid.com>,
Mark Conrad <NoMailAccepted@invalid.com> wrote:

In article <nospam.News.Bob-533D6D.21124314042006@news.verizon.net>,
Bob Harris <nospam.News.Bob@remove.Smith-Harris.us> wrote:

In my Pismo with OS 10.4.6 there are 25,725 directories (folders), so that means there are roughly the same number of .DS_Store files, one in each directory.

My iBook only has 1389 .DS_Store files out of 109239 directories
(1.27 percent)

Most of the directories on the system are System, Library, caches,
etc... where either the Finder does not see, or you as a user do
not navigate to with the Finder. Hence no .DS_Store files

Thanks for straightening me out on that.

This is why these NGs are so great, any mis-conceptions get cleared up
by others who know more about the subject.

By the way, I found out how many .DS_Store files I had by using

locate .DS_Store | wc

Great tip, I will add that to my limited Unix arsenal, thanks.

of course I also have root run the nightly
/usr/libexec/locate.updatedb
job that updates the locate database, but that is a totally
different subject.

Sounds useful, but I thought that OS X had some mechanism that
periodically updated the 'locate' database?

Of course, if the auto' update feature does not work often enough, it
could be a bit useless whenever a 'locate' search was done.

Being the newest Intel based Macs no longer run Classic, it now appears there is no reason to hang onto those .DS_Store files, so I would not
be surprised to see Apple abandon all those many thousands of .DS_Store files, one .DS_Store file per directory, in future versions of their OS
- - - and replace them with some centralized method of doing the minor things that are now being done by thousands of scattered .DS_Store files.

I disagree. Mac OS 9 (and earlier) never used .DS_Store files, so
they are a MacOSX invention (or maybe a NeXT invention, but
definitely not Classic or Mac OS 9 or earlier).

Hokay, that's what I get for listening to gossip on the net.<g>

Whenever you delete a .DS_Store file, all the above things return to default values, i.e. the icons jump to default locations in a window,
the window size itself jumps to a default size, and Spotlight
"comments" revert to blank (no comments).

Also, _no_ "new" .DS_Store file gets created, not even if you
restart your Mac.

Not even creating a new file will cause a new .DS_Store file to be created, provided you do not move any icons in the window, or rezize
the window.

However, _if_ you move any icons, or change the window size, or "automatically" re-arrange all the icons in the window, _then_ a .DS_Store file gets created again.

So you just proved my point. There are not 1000's of .DS_Store
files on the file system. Just a thousand or so. Or just over 1%
of the directories contain .DS_Store files.

On my system all the .DS_Store files take up a total of 13MB. I
have more than that tied up in some graphics files or a long .mp3
music file. And since I have a 100GB disk (93 real GB), that is
0.01% of my disk storage). And if you disk is as small as 6GB
then this would be only 0.2%. This is noise and not a major
concern for me or most people.

I found out how much space my .DS_Store files were using via:
sudo find / -name ".DS_Store" -print0 |\
xargs -0 ls -s |\
awk '{size += $1} END{print size}'

Thanks very much for all that info', especially the last part about
finding how much disk space is being used for all the DS files.

I have a book about Terminal scripting on order, hope I can understand
the Unix stuff therein, when it arrives:
Mastering Unix Shell Scripting
by author Randal K. Michael

UNIX scripting is very powerful and flexible. A lot of its power
comes from piping the output of one command into another. For
example the following was one of the first UNIX spell checkers:

tr -C 'a-zA-Z' '\n' <file_to_spell_check |\
sort |\
uniq |\
comm -23 - /usr/share/dict/words

Each program was small (the most complex was most likely the sort
utility). And none of the programs in and of themselves have
anything to do with spelling or word processing per say. But line
them up in a pipeline and you have a rude and crude spell checker.
And in its day it was a very useful spell checker.

When I first saw this script, I was in totally amazed! I fell in
love with UNIX scripting then and there.

Now some comments about my little script. 'find' is extremely
useful, and I find that 'xargs' enhances 'find' a lot. And
knowing about find's -print0 and xargs' -0 options can be most
handly.

'find' has a lot of options. But for the most part, I've mostly
used the -name, the -type, and -xdev, options. I've used some
others, but less frequently than the above. And a lot of my
'find' usage is NOT for the entire disk. Generally it is just a
local directory or directory sub-tree. One useful trick to know
about 'find' is that many numeric arguments allow a leading + or -
to indicate greater than or less than the specified value. For
example:

find / -xdev -size +20480

will find all the files on your boot disk which are greater than
10MB (20480 * 512 == 10MB).

Enough about 'find'. In my "find / -name .DS_Store" example, I
had xargs run the "ls -s" command for each file found. "ls -s"
give the storage allocated to each file in 1K units. It looks like

16 .DS_Store

So this .DS_Store is 16K in size.

The output from the xargs and all the "ls -s" commands is piped
into an awk script.

Awk is a powerful small text manipulation language that looks a
lot like C, so C programmers like myself like. It is not as
powerful as Perl, or Python, Ruby, but I learned awk in '85 and at
that time there was no competition. It is also perfectly suitable
for this task.

awk '{size += $1} END{print size}'

Unrolling this a little bit

awk '
{ size += $1 }
END {
print size
}'

The script commands are located between the '...'

Awk executes the script for each line read.

The END statement only does something when the end-of-file is
detected (in our case when 'find' stops, it closes its side of the
pipe, which sends end-of-file to xargs; xargs then closes its end
of the pipe to awk, which sends end-of-file to awk).

Getting a little more general about awk. Each awk statement is of
the form

conditional expression { actions }

The conditional expression can be a search string as in /abc/ or a
regular expression (UNIX loves regular expressions), such as
/[a-zA-Z0-9]/. It can be something like $1 == "abc" or $3 < 27,
and it can be multiple exprssions. $2 > 6 && $3 != "Fred", etc...

If the conditional expression results in TRUE, then the Action is
performed.

If there is no conditional expression, then the action phase is
always performed.

The Action can look like a C program, with 'if' statments, print,
variable assignments, math, for loops, except that awk has much
better string handling than C.

If there is no action specified, then "print $0" is preformed. $0
is the entire input line. $1 is the first white space separated
word, $2 is the 2nd word, $3 is the third, etc...

So what my little script did, was to take all of the "16
.DS_Store", "24 .DS_Store", "4 .DS_Store", etc... input lines, and
add up the size fields, then as its last task before exiting,
print the total.

The following is a well written into to awk. You will still want
to read the man page. I think with this into, and the man page
you can write some very useful awk scripts:

Matching Patterns and Processing Information with awk <http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51A_HTML/AR H9WATE/WKXXXXXX.HTM>

I find your posting style very refreshing, because most Unix pros here
merely give vague broad hints on Unixy stuff, then expect me to do
_all_ the hard work of digging out the essential details.

You manage to work those details directly into your posts, which has
the benefit of actually showing us non-Unix types that Unix is good for
the practical everyday operation of a Mac.

If you every decide to write a Unix book, let me know so I can be the
first one standing in line for the book.

Anything written by Brian W. Kernighan. He is clear, brief, and
he includes short, clean and powerful examples, which actually
work in all his writings. I may not have read everything he has
written, but I do have most of the computer books he has published.

Time to go to lunch :-)

Bob Harris

About deleting .DS_Store files
*********************

But if you want to delete them, have fun.

Naw, as I stated near the start of this thread, my interest in the DS
files is just a matter of curiousity.

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.mac.system

In article <nospam.News.Bob-98BD14.12573215042006@news.verizon.net>,
Bob Harris <nospam.News.Bob@remove.Smith-Harris.us> wrote:

UNIX scripting is very powerful and flexible. A lot of its power
comes from piping the output of one command into another.

It is a shame, but I have not managed to free up the time to tap that
kind of power.

Same old story, everyone has priorities of what they _have_ to do
with their time.

What little time I have devoted to Unix has rewarded me, so I try to
encourage other Mac users to take advantage of Unix resources.

To me, the ready access to Unix on the Mac is one of the strong reasons
for choosing a Mac instead of a PC.



I will be satisfied to grab just bits and pieces of Unix. I no longer
have enough time left to do anything except that, because presently I
am extremely busy on two fronts:

1) Beating off the grim reaper for a short time. A losing battle,
stuff is falling apart faster than I can patch it. Going in for a
double cataract surgery two weeks from now. Ticker worn out, etc.

2) Frantically avoiding abject poverty. I made the huge mistake of
taking my company pension for only ten years starting 1989, because I
come from a very short-lived family. Father died at 45. (I am 76)

No regrets, had a very good life.

So you see, I am not exactly an ideal candidate for learning Unix.<g>


Beware, Long Off Topic Lisp Rant - - - Do Not Read *************************************
Myself, I hit programming very late in my life, so did not get much of
a chance to apply my efforts. Strictly prototyping, using Scheme and
Common Lisp.

Emacs might be useful to me for implementing Unix scripts, because of
the Lisp roots of Emacs.

Unfortunately, the underlying Lisp in Emacs is an ancient subset of
MacLisp, so that might cripple what can be done in the way of Unix
script programming.

Lisp has advanced since those early days, modern Lisps are much more
powerful than the old version in Emacs.

It is doubtful whether _any_ Lisp, modern or old, can grab a Unix
app' "directly". (can Emacs?)

Modern Lisps _do_ have C hooks, so if all Unix app's have those, I
might be in business.

Generally, Lisp's prime use is to get a new-concept application running
for the first time, quickly, just to establish "Proof of Concept" - - -
i.e., that it is "possible" to design the guts of the application to
run in such a manner as to succeed.

That way, the C guys do not waste their time trying to construct an
app' that does not have any chance of running properly.

A sharp Lisp programmer can construct his final Lisp prototype in such
a fashion that the C programmers can almost use it as a "paint by
numbers" guide for constructing the final C version of the Lisp
program.
(i.e., no recursion, only iteration - - - no lexical closures, no Lisp
macros, all of them "expanded" - - - heavy typing, for the benefit of
the C programmer - - - all "tricky" Lisp stuff like order-of-evaluation
of arguments set to what the C guys expect)

All the above simple modifications of the Lisp code, plus much more
advanced stuff like exotic code walkers etc. should be simplified as
much as time permits, to help the C guys.

All the exotic Lisp stuff is geared to one goal, namely to make as fast
a prototyping language as possible. Typically, a Lisp prototype could
take a few months to complete, with a few Lisp programmers.

The same program effort in C/C++ could take a few years to complete,
with many teams of programmers. Reason, the design of C/C++ sacrifices
top level flexibility for speed of operation and a small code
footprint.

The hundred C guys do not have to wait for the five Lisp guys, because
the Lisp guys are always a few projects ahead, waiting for the C teams
to finish their present project.

It is a sad fact that no present programming language can implement the
top level prototyping flexibility of Lisp along with the speed and size
of C and/or assembly "language".

Anyhow, once "Proof of Concept" is established by the running Lisp
program, the Lisp is entirely abandoned, and the C/C++ programmers
start building the same program from scratch - - - possibly using the
junked Lisp program as a rough guide.

The C guys _know_ their C program will run okay when finished,
because the Lisp version ran okay.

...and the Mac guys design the GUI interface. Hopefully the C guys
left enough hooks to accomodate the Mac guys. *************************************
End of Lisp Rant

Mark-
--- Synchronet 3.18b-Win32 NewsLink 1.113