Discussion:
preventing .DS_Store file creation in jar in OSX?
(too old to reply)
Bill Christens-Barry
2006-07-19 16:17:49 UTC
Permalink
How do I prevent the jar command from creating a .DS_Store file in the
jar that it creates? Alternatively, how do I remove (different from
extract) the .DS_Store file from a jar?

Thanks.

Bill Christens-Barry
Steve W. Jackson
2006-07-19 17:42:05 UTC
Permalink
Post by Bill Christens-Barry
How do I prevent the jar command from creating a .DS_Store file in the
jar that it creates? Alternatively, how do I remove (different from
extract) the .DS_Store file from a jar?
Thanks.
Bill Christens-Barry
The simplest thing is just to eliminate those files from your directory
structure before creating the jar file, I would imagine. Alternatively,
you might see if JarBundler or some other tool on the Mac has the
ability to build your jar as you like and not include those files.

= Steve =
--
Steve W. Jackson
Montgomery, Alabama
Bill Christens-Barry
2006-07-19 18:48:01 UTC
Permalink
Thanks, Steve. The problem is that there is no pre-existing .DS_Store
file in the directory. The Mac under OSX creates these files in a number
of contexts, although I'm not up on the details, and it presents an
irritation since they are visible on other OSs.

Bill C-B
Post by Steve W. Jackson
Post by Bill Christens-Barry
How do I prevent the jar command from creating a .DS_Store file in the
jar that it creates? Alternatively, how do I remove (different from
extract) the .DS_Store file from a jar?
Thanks.
Bill Christens-Barry
The simplest thing is just to eliminate those files from your directory
structure before creating the jar file, I would imagine. Alternatively,
you might see if JarBundler or some other tool on the Mac has the
ability to build your jar as you like and not include those files.
= Steve =
Steve W. Jackson
2006-07-19 20:39:00 UTC
Permalink
Post by Bill Christens-Barry
Thanks, Steve. The problem is that there is no pre-existing .DS_Store
file in the directory. The Mac under OSX creates these files in a number
of contexts, although I'm not up on the details, and it presents an
irritation since they are visible on other OSs.
Bill C-B
Post by Steve W. Jackson
Post by Bill Christens-Barry
How do I prevent the jar command from creating a .DS_Store file in the
jar that it creates? Alternatively, how do I remove (different from
extract) the .DS_Store file from a jar?
Thanks.
Bill Christens-Barry
The simplest thing is just to eliminate those files from your directory
structure before creating the jar file, I would imagine. Alternatively,
you might see if JarBundler or some other tool on the Mac has the
ability to build your jar as you like and not include those files.
= Steve =
Top-posting strikes again...

The Mac OS X Finder uses the .DS_Store files to store preferences for
the display of its windows opened for a given directory; when none is
present, it falls back to defaults. Unless someone opens a Finder
window into one of the directories that will ultimately be copied into
the new jar file, there's no reason one should ever get created there.
There *must* be one pre-existing or otherwise copied into the locations
that are being included in the jar file.

I don't know what process you might be using to compile your code and
build your jar file. When we're building for a release, the class files
are placed in separate location from the source, and it's created from
scratch. The process is thus completely immune to the possibility of
.DS_Store files ending up in the resulting directory, and then in the
jar file built from it.

= Steve =
--
Steve W. Jackson
Montgomery, Alabama
steve
2006-07-19 22:15:22 UTC
Permalink
Post by Steve W. Jackson
Post by Bill Christens-Barry
Thanks, Steve. The problem is that there is no pre-existing .DS_Store
file in the directory. The Mac under OSX creates these files in a number
of contexts, although I'm not up on the details, and it presents an
irritation since they are visible on other OSs.
Bill C-B
Post by Steve W. Jackson
Post by Bill Christens-Barry
How do I prevent the jar command from creating a .DS_Store file in the
jar that it creates? Alternatively, how do I remove (different from
extract) the .DS_Store file from a jar?
Thanks.
Bill Christens-Barry
The simplest thing is just to eliminate those files from your directory
structure before creating the jar file, I would imagine. Alternatively,
you might see if JarBundler or some other tool on the Mac has the
ability to build your jar as you like and not include those files.
= Steve =
Top-posting strikes again...
The Mac OS X Finder uses the .DS_Store files to store preferences for
the display of its windows opened for a given directory; when none is
present, it falls back to defaults. Unless someone opens a Finder
window into one of the directories that will ultimately be copied into
the new jar file, there's no reason one should ever get created there.
There *must* be one pre-existing or otherwise copied into the locations
that are being included in the jar file.
I don't know what process you might be using to compile your code and
build your jar file. When we're building for a release, the class files
are placed in separate location from the source, and it's created from
scratch. The process is thus completely immune to the possibility of
.DS_Store files ending up in the resulting directory, and then in the
jar file built from it.
= Steve =
the .ds_store , files do not need the window to be opened, they often appear
in directories that have never been opened in the finder.

However , that said, Linux and the cvs systems also have a lot of similar
files scattered about their directory structures
if you use an IDE to build your jar files, most ide's allow an exemption list
, which excludes the named files from any build or system process.

steve
Steve W. Jackson
2006-07-20 18:00:13 UTC
Permalink
In article <***@news1.newsguy.com>, steve <***@aol.com> wrote:

[ snip ]
Post by steve
the .ds_store , files do not need the window to be opened, they often appear
in directories that have never been opened in the finder.
However , that said, Linux and the cvs systems also have a lot of similar
files scattered about their directory structures
if you use an IDE to build your jar files, most ide's allow an exemption list
, which excludes the named files from any build or system process.
steve
You'll have to show me evidence of the unprovoked appearance of
.DS_Store files. In my years of using OS X, I've never found it to be
the case.
--
Steve W. Jackson
Montgomery, Alabama
Gregory Weston
2006-07-22 00:41:48 UTC
Permalink
Post by Steve W. Jackson
[ snip ]
Post by steve
the .ds_store , files do not need the window to be opened, they often appear
in directories that have never been opened in the finder.
However , that said, Linux and the cvs systems also have a lot of similar
files scattered about their directory structures
if you use an IDE to build your jar files, most ide's allow an exemption list
, which excludes the named files from any build or system process.
steve
You'll have to show me evidence of the unprovoked appearance of
.DS_Store files. In my years of using OS X, I've never found it to be
the case.
It can be done, if something programmatically sets a property of the
folder or a contained file that is among the things that are stored in a
.DS_Store file. Here's my contrived example...

In Terminal:

mkdir foo;cd foo;touch blarg;ls -la

(Creates a pristine directory, creates a file in it, and shows that
there's no .DS_Store.)

In Script Editor:

tell application "Finder"
set theFile to file "blarg" of folder "foo" of folder "greg" of
folder "Users" of disk "Macintosh HD"
set comment of theFile to "arglebargle"
end tell

In Terminal:

ls -la

(Now there's a .DS_Store.)



Now, I'd say that to say they "often" appear in directories that haven't
been opened by Finder is not a general truth, but it could be that
someone has and regularly uses a tool that for some reason sets those
properties.
--
What I write is what I mean. I request that anyone who decides to respond
please refrain from "disagreeing" with something I didn't write in the first
place.
Loading...