Thanks for that, Mike
I guess this goes far further than just JBoss-Jetty now.
The short term solution to the immediate problem is, as several people have suggested,
to put
a dummy file in empty directories. The wider problems made apparent in your mail will
need
some thought by the guys in charge.
I certainly know a lot more about tar and zips than I did before....
Cheers,
Jules
Michael Bilow wrote:
> 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
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
