Re: [JBoss-user] jboss/db/jbossmq disappearing....

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

The Info-ZIP compression/decompression tools have radically different
default behaviors than the old PK-derived tools.  For example, on DOS,
PKUNZIP flattens all files into the current directory by default and
strips all subdirectory information unless the "-d" switch is given.  
With the Info-ZIP tools, like "tar" you get subdirectories by default
unless you explicitly "junk" them with the "-j" switch.  WiZ, a freeware
clone of WinZip from the Info-ZIP project, obviously uses the Info-ZIP
engine on Windows in DLL form, so it has the default Info-ZIP behavior.  
Some people are probably using "jar" to unzip distribution ZIP files!

Considering how little control you will ever have over how people choose
to extract your distribution archive, I think your only safe option is to
put something like a "README.txt" file into the directory to ensure that
it is not empty.  As far as I know, this will guarantee on all tools that
the directory is created (if the tool is subdirectory-aware at all).

There is no way for you to deal with ownership and permissions issues
except as part of a larger policy which provides a framework for this.  
For example, on our systems all parts of the distribution are owned by
"root" in group "jboss," and those parts to which the running jBoss system
needs read-only access have mode 750 for directories or 640 for files,
while those parts for which the running jBoss system needs read-write
access have mode 770 for directories or 660 for files.  This guarantees
that jBoss does not have sufficient privilege to modify its own code or
configuration on disk, one of the most commonly exploited security
vulnerabilities on Unix.  The jBoss process itself runs as the "jboss"
system user, who (like users "mail" or "ftp") has no login privilege.

Such a framework for ownership and permission would be a huge help on
Unix, since that would effectively standardize the installation format and
centralize maintenance of it.  Right now, we have to manually configure
the ownership and permission of every single directory and file which is
unpacked from the distribution on Unix.  There is also at present no
expectations that any two different Unix installations have comparable
configurations, which makes bugs more likely and diagnosis more difficult.

Part of the problem, of course, is that ZIP files have no standard way of
carrying ownership and permission information.  The "tar" file format
does, since it is POSIX-standardized, but people do not seem to like using
"tar" format on DOS/Windows.  Info-ZIP defines a private extension on
operating systems which have ownership and permission capabilities, so
that this information can be carried by the ZIP file if Info-ZIP tools are
used for both archiving and dearchiving.  Oddly, the default behavior on
Unix is for "zip" to put ownership and permission information into the
archive and then for "unzip" to throw it away upon dearchiving!  (Use the
"-X" switch to override the default behavior on Unix.  That is, "zip -X"
will NOT record ownership and permission information, and "unzip -X" will
NOT throw it away.)

Although there is no standard extension format for ZIP, there is a
standard format (originally definied by PKZIP) for declaring extensions.  
As a result, any ZIP tool should be able to tell that there is some sort
of extension present, but it may not be able to distinguish whether the
extension is Unix ownership and permission information, an OS/2 extended
attribute block, or a MacOS resource fork.  Info-ZIP supports all of these
types of extensions, but they are only meaningful if Info-ZIP tools are
used for both archiving and dearchiving, even across platforms.  The Unix
"zipinfo" tool (really "unzip -Z ...") can display these.

Note that Sun uses the Info-ZIP tools (or at least their file formats) to
distribute the Linux JDK.  This is necessary because there is no other way
to encapsulate critical information needed by Linux, such as symbolic
links in the filesystem.  Distribution file j2sdk-1_3_1-linux-i386
examined with "zipinfo" shows Info-ZIP extensions decoded.  Here is the
main "java" binary in the archive:

-rwxrwxr-x  2.2 unx    27058 bx defN  6-May-01 06:15
jdk1.3.1/jre/bin/i386/native_threads/java

Here is a symbolic link (the contents of which when uncompressed are the
link's target):

lrwxrwxrwx  2.2 unx       13 bx stor  6-May-01 06:41
jdk1.3.1/jre/bin/java

The coding "2.2 unx" means that the archive was created (by Sun) using
Info-ZIP v2.2 on Unix.  If the ZIP distributions for jBoss are built on
Linux using the Info-ZIP tools, this would make life a great deal easier
for Unix installations and remain perfectly compatible with Windows.

-- Mike

On 2001-06-23 at 19:24 +0100, Julian Gosnell wrote:

> All the .tgz files I have checked in to binaries have this directory intact :
> 
> /home/jules/cvs/JBoss/binaries/JBoss-2.2.2_Jetty-3.1.RC5-2.tgz
> drwxrwxr-x jules/jules       0 2001-06-10 23:29:02
> JBoss-2.2.2_Jetty-3.1.RC5-2/jboss/db/jbossmq/
> /home/jules/cvs/JBoss/binaries/JBoss-2.2.2_Jetty-3.1.RC5-3.tgz
> drwxrwxr-x jules/jules       0 2001-06-14 01:24:50
> JBoss-2.2.2_Jetty-3.1.RC5-3/jboss/db/jbossmq/
> /home/jules/cvs/JBoss/binaries/JBoss-2.2.2_Jetty-3.1.RC5-4.tgz
> drwxrwxr-x jules/jules       0 2001-06-21 23:08:56
> JBoss-2.2.2_Jetty-3.1.RC5-4/jboss/db/jbossmq/
> /home/jules/cvs/JBoss/binaries/JBoss-2.2.2_Jetty-3.1.RC5-5.tgz
> drwxrwxr-x jules/jules       0 2001-06-23 10:48:38
> JBoss-2.2.2_Jetty-3.1.RC5-5/jboss/db/jbossmq/
> /home/jules/cvs/JBoss/binaries/JBoss-2.2.2_Jetty-3.1.RC5.tgz
> drwxrwxr-x jules/jules       0 2001-06-05 00:40:34
> JBoss-2.2.2_Jetty-3.1.RC5/jboss/db/jbossmq/
> /home/jules/cvs/JBoss/binaries/jboss-jetty.01-05-21.tgz
> drwxrwxr-x jules/jules       0 2001-05-21 23:39:12 jboss-jetty.01-05-21/jboss/db/jbossmq/
> 
> 
> 
> unzip -l -ing the zipped release available from the web-site gives this :
> 
>         0  06-05-01 00:40   JBoss-2.2.2_Jetty-3.1.RC5/jboss/db/jbossmq/
> 
> the .tar.gz ;
> 
> drwxrwxr-x jules/jules       0 2001-06-05 00:40:34
> JBoss-2.2.2_Jetty-3.1.RC5/jboss/db/jbossmq/
> 
> and the .tar.bz2:
> 
> drwx------ alborini/promo01      0 2001-06-05 00:40:34
> JBoss-2.2.2_Jetty-3.1.RC5/jboss/db/jbossmq/
> 
> 
> 
> So,
> 
> As far as the tools I use go (linux - RedHat 6.2), this directory is intact in the
> releases.
> 
> I guess that for some reason when people unpack the release they are losing it. Could it
> be permissions based ? It makes me wonder how many other directories are just
> disappearing ?
> 
> If the dir is getting lost because it is empty, perhaps we could just 'touch' a dummy
> file in there to prevent this ? What do people think ?
> 
> 
> Jules