From vapier at gentoo.org Thu Jan 12 05:22:15 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 11 Jan 2006 22:22:15 -0500 Subject: USE_ARRAY_FOR_64BIT_TYPES logic broken ? Message-ID: <200601112222.15447.vapier@gentoo.org> i was cross-compiling file-4.16 for an amd64/uClibc host and when i tried to use it natively, it kept giving me crap like: /bin/bash: ERROR: error seeking (Invalid argument) i traced it back to configure setting the size of all the uint types (8/16/32/64 bits) to 0 because it was a cross-compile, thus forcing the logic of USE_ARRAY_FOR_64BIT_TYPES to be enabled for example, this code: if (dophn_core(ms, class, swap, fd, #ifdef USE_ARRAY_FOR_64BIT_TYPES (off_t)getu32(swap, elfhdr.e_phoff[1]), #else (off_t)getu64(swap, elfhdr.e_phoff), #endif getu16(swap, elfhdr.e_phnum), (size_t)getu16(swap, elfhdr.e_phentsize)) == -1) that getu32() only swaps & uses the 2nd set of 32bits and disregards the first set of 32bits (thus leading to my funky problem of bogus lseek() calls) -mike From christos at zoulas.com Thu Jan 12 15:55:02 2006 From: christos at zoulas.com (Christos Zoulas) Date: Thu, 12 Jan 2006 08:55:02 -0500 Subject: USE_ARRAY_FOR_64BIT_TYPES logic broken ? In-Reply-To: <200601112222.15447.vapier@gentoo.org> from Mike Frysinger (Jan 11, 10:22pm) Message-ID: <20060112135502.46B1C56534@rebar.astron.com> On Jan 11, 10:22pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: USE_ARRAY_FOR_64BIT_TYPES logic broken ? | i was cross-compiling file-4.16 for an amd64/uClibc host and when i tried to | use it natively, it kept giving me crap like: | /bin/bash: ERROR: error seeking (Invalid argument) | | i traced it back to configure setting the size of all the uint types | (8/16/32/64 bits) to 0 because it was a cross-compile, thus forcing the logic | of USE_ARRAY_FOR_64BIT_TYPES to be enabled | | for example, this code: | if (dophn_core(ms, class, swap, fd, | #ifdef USE_ARRAY_FOR_64BIT_TYPES | (off_t)getu32(swap, elfhdr.e_phoff[1]), | #else | (off_t)getu64(swap, elfhdr.e_phoff), | #endif | getu16(swap, elfhdr.e_phnum), | (size_t)getu16(swap, elfhdr.e_phentsize)) == -1) | | that getu32() only swaps & uses the 2nd set of 32bits and disregards the first | set of 32bits (thus leading to my funky problem of bogus lseek() calls) | -mike Yes, this logic is bogus and it will only work on big endian machines for small offsets. The small offsets problem is probably ok, but the big endian is not. We need to deal with endianness properly, at which point we should read both words :-) christos From vapier at gentoo.org Thu Jan 12 15:58:59 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 12 Jan 2006 08:58:59 -0500 Subject: USE_ARRAY_FOR_64BIT_TYPES logic broken ? In-Reply-To: <20060112135502.46B1C56534@rebar.astron.com> References: <20060112135502.46B1C56534@rebar.astron.com> Message-ID: <200601120858.59528.vapier@gentoo.org> On Thursday 12 January 2006 08:55, Christos Zoulas wrote: > On Jan 11, 10:22pm, vapier at gentoo.org (Mike Frysinger) wrote: > -- Subject: USE_ARRAY_FOR_64BIT_TYPES logic broken ? > > | i was cross-compiling file-4.16 for an amd64/uClibc host and when i tried > | to use it natively, it kept giving me crap like: > | /bin/bash: ERROR: error seeking (Invalid argument) > | > | i traced it back to configure setting the size of all the uint types > | (8/16/32/64 bits) to 0 because it was a cross-compile, thus forcing the > | logic of USE_ARRAY_FOR_64BIT_TYPES to be enabled > | > | for example, this code: > | if (dophn_core(ms, class, swap, fd, > | #ifdef USE_ARRAY_FOR_64BIT_TYPES > | (off_t)getu32(swap, elfhdr.e_phoff[1]), > | #else > | (off_t)getu64(swap, elfhdr.e_phoff), > | #endif > | getu16(swap, elfhdr.e_phnum), > | (size_t)getu16(swap, elfhdr.e_phentsize)) == -1) > | > | that getu32() only swaps & uses the 2nd set of 32bits and disregards the > | first set of 32bits (thus leading to my funky problem of bogus lseek() > | calls) > > Yes, this logic is bogus and it will only work on big endian machines for > small offsets. The small offsets problem is probably ok, but the big endian > is not. We need to deal with endianness properly, at which point we should > read both words :-) are you going to write something or would you like me to post a patch ? i could have one tonight for you ... -mike From christos at zoulas.com Thu Jan 12 16:06:10 2006 From: christos at zoulas.com (Christos Zoulas) Date: Thu, 12 Jan 2006 09:06:10 -0500 Subject: USE_ARRAY_FOR_64BIT_TYPES logic broken ? In-Reply-To: <200601120858.59528.vapier@gentoo.org> from Mike Frysinger (Jan 12, 8:58am) Message-ID: <20060112140610.2312C56534@rebar.astron.com> On Jan 12, 8:58am, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: Re: USE_ARRAY_FOR_64BIT_TYPES logic broken ? | are you going to write something or would you like me to post a patch ? i | could have one tonight for you ... | -mike Please do. I never turn down gracious offers like this! :-) christos From vapier at gentoo.org Fri Jan 13 00:54:12 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 12 Jan 2006 17:54:12 -0500 Subject: USE_ARRAY_FOR_64BIT_TYPES logic broken ? In-Reply-To: <20060112140610.2312C56534@rebar.astron.com> References: <20060112140610.2312C56534@rebar.astron.com> Message-ID: <200601121754.12111.vapier@gentoo.org> how does the attached patch look ? cross-compiling for amd64 target gives a working binary now ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: file-4.16-fix-array-64bit.patch Type: text/x-diff Size: 1942 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060112/12ae2488/file-4.16-fix-array-64bit.bin From christos at zoulas.com Fri Jan 13 02:44:00 2006 From: christos at zoulas.com (Christos Zoulas) Date: Thu, 12 Jan 2006 19:44:00 -0500 Subject: USE_ARRAY_FOR_64BIT_TYPES logic broken ? In-Reply-To: <200601121754.12111.vapier@gentoo.org> from Mike Frysinger (Jan 12, 5:54pm) Message-ID: <20060113004400.A084156534@rebar.astron.com> On Jan 12, 5:54pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: Re: USE_ARRAY_FOR_64BIT_TYPES logic broken ? | how does the attached patch look ? cross-compiling for amd64 target gives a | working binary now ... | -mike Looks great and applied! Thanks Mike! christos From vapier at gentoo.org Fri Mar 3 06:56:04 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 2 Mar 2006 23:56:04 -0500 Subject: file 4.17 preview... In-Reply-To: <20060302222309.D2C2F56534@rebar.astron.com> References: <20060302222309.D2C2F56534@rebar.astron.com> Message-ID: <200603022356.04202.vapier@gentoo.org> On Thursday 02 March 2006 17:23, Christos Zoulas wrote: > 2006-03-02 16:06 Christos Zoulas > > * Print empty if the file is (Mike Frysinger) > > * Don't try to read past the end of the buffer (Mike Frysinger) i dont remember what patches these were :), but the attached test case by Erik Thiele still fails with file-4.17 ... -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: magic-test.c Type: text/x-csrc Size: 259 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060303/9cead1fb/attachment.bin From christos at zoulas.com Fri Mar 3 21:05:19 2006 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 3 Mar 2006 14:05:19 -0500 Subject: file 4.17 preview... In-Reply-To: <200603022356.04202.vapier@gentoo.org> from Mike Frysinger (Mar 2, 11:56pm) Message-ID: <20060303190519.F3C2F56534@rebar.astron.com> On Mar 2, 11:56pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: Re: file 4.17 preview... | i dont remember what patches these were :), but the attached test case by Erik | Thiele still fails with file-4.17 ... | -mike Ah, not one, but two bugs to fix this one :-) christos =================================================================== RCS file: /src/pub/file/src/ascmagic.c,v retrieving revision 1.44 diff -u -u -r1.44 ascmagic.c --- ascmagic.c 2 Mar 2006 22:08:22 -0000 1.44 +++ ascmagic.c 3 Mar 2006 19:04:17 -0000 @@ -154,8 +154,10 @@ } } - if (nbytes <= 1) + if (nbytes <= 1) { + rv = 0; goto done; + } /* * for troff, look for . + letter + letter or .\"; Index: softmagic.c =================================================================== RCS file: /src/pub/file/src/softmagic.c,v retrieving revision 1.77 diff -u -u -r1.77 softmagic.c --- softmagic.c 20 Oct 2005 14:59:01 -0000 1.77 +++ softmagic.c 3 Mar 2006 19:04:17 -0000 @@ -664,6 +664,11 @@ * (starting at 1), not as bytes-from start-of-file */ char *b, *c, *last = NULL; + if (s == NULL) { + p->search.buflen = 0; + p->search.buf = NULL; + return 0; + } if ((p->search.buf = strdup((const char *)s)) == NULL) { file_oomem(ms); return -1; From vapier at gentoo.org Sat Mar 4 04:13:37 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Fri, 3 Mar 2006 21:13:37 -0500 Subject: file 4.17 preview... In-Reply-To: <20060303190519.F3C2F56534@rebar.astron.com> References: <20060303190519.F3C2F56534@rebar.astron.com> Message-ID: <200603032113.37233.vapier@gentoo.org> On Friday 03 March 2006 14:05, Christos Zoulas wrote: > On Mar 2, 11:56pm, vapier at gentoo.org (Mike Frysinger) wrote: > -- Subject: Re: file 4.17 preview... > > | i dont remember what patches these were :), but the attached test case by > | Erik Thiele still fails with file-4.17 ... > > Ah, not one, but two bugs to fix this one :-) confirmed, patch works nicely ! -mike From vapier at gentoo.org Tue Mar 14 01:40:53 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 13 Mar 2006 18:40:53 -0500 Subject: segfault in file-4.17 Message-ID: <200603131840.53886.vapier@gentoo.org> seems i missed this in the earlier request for testing since i only tested amd64, sorry :/ on Gentoo/x86 systems, a bunch of users have been hitting segfaults when compiling the magic files during build (Bug 126012): ../src/file -C -m magic make[2]: *** [magic.mgc] Segmentation fault the crash appears to be in libmagic.so as using `file` 4.16 but libgmagic.so from 4.17 also crashes ... looking through the 4.16 and 4.17 diff, i noticed this change in the apprentice_file() func in src/apprentice.c: maxmagic = MAXMAGIS; - *magicp = (struct magic *) calloc(maxmagic, sizeof(struct magic)); - if (*magicp == NULL) { + if ((marray = malloc(maxmagic * sizeof(*marray))) == NULL) { (void)fclose(f); i dont know whether this change was on purpose, but reverting it does fix the crash for me ... in the attached patch, i also removed an unused variable -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: file-init-mem.patch Type: text/x-diff Size: 581 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060314/602b4c38/attachment.bin From christos at zoulas.com Tue Mar 14 01:50:20 2006 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 13 Mar 2006 18:50:20 -0500 Subject: segfault in file-4.17 In-Reply-To: <200603131840.53886.vapier@gentoo.org> from Mike Frysinger (Mar 13, 6:40pm) Message-ID: <20060313235020.239BD56534@rebar.astron.com> On Mar 13, 6:40pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: segfault in file-4.17 | seems i missed this in the earlier request for testing since i only tested | amd64, sorry :/ | | on Gentoo/x86 systems, a bunch of users have been hitting segfaults when | compiling the magic files during build (Bug 126012): | ../src/file -C -m magic | make[2]: *** [magic.mgc] Segmentation fault | | the crash appears to be in libmagic.so as using `file` 4.16 but libgmagic.so | from 4.17 also crashes ... looking through the 4.16 and 4.17 diff, i noticed | this change in the apprentice_file() func in src/apprentice.c: | maxmagic = MAXMAGIS; | - *magicp = (struct magic *) calloc(maxmagic, sizeof(struct magic)); | - if (*magicp == NULL) { | + if ((marray = malloc(maxmagic * sizeof(*marray))) == NULL) { | (void)fclose(f); | | i dont know whether this change was on purpose, but reverting it does fix the | crash for me ... in the attached patch, i also removed an unused variable | -mike | Thanks, I see the problem now. I have fixed it as you suggested. christos From vapier at gentoo.org Tue Mar 14 02:44:16 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 13 Mar 2006 19:44:16 -0500 Subject: [patch] fix minor warning in funcs.c Message-ID: <200603131944.16308.vapier@gentoo.org> when i was playing around with the code earlier, i noticed a minor warning in funcs.c about implicit definition of iswprint() ... simple patch attached to include wctype.h when available and thus get access to the prototype side note ... configure.ac currently calls AC_CHECK_HEADERS() multiple times ... all the calls could be condensed into one ... doing so shaves like 47k off of configure :) -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: file-wctype-header.patch Type: text/x-diff Size: 539 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060314/71cf56e8/attachment.bin From christos at zoulas.com Tue Mar 14 03:02:05 2006 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 13 Mar 2006 20:02:05 -0500 Subject: [patch] fix minor warning in funcs.c In-Reply-To: <200603131944.16308.vapier@gentoo.org> from Mike Frysinger (Mar 13, 7:44pm) Message-ID: <20060314010206.0AD1656534@rebar.astron.com> On Mar 13, 7:44pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: [patch] fix minor warning in funcs.c | | when i was playing around with the code earlier, i noticed a minor warning in | funcs.c about implicit definition of iswprint() ... simple patch attached to | include wctype.h when available and thus get access to the prototype | | side note ... configure.ac currently calls AC_CHECK_HEADERS() multiple | times ... all the calls could be condensed into one ... doing so shaves like | 47k off of configure :) | -mike This looks good to me... christos From vapier at gentoo.org Tue Mar 14 03:06:28 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 13 Mar 2006 20:06:28 -0500 Subject: misdetection of flac file w/id3 tag as mp3 Message-ID: <200603132006.28261.vapier@gentoo.org> a Gentoo user filed Bug 124872 where they reported some of their flac files being misreported as mp3s ... ive got an example file here: http://wh0rd.org/flacid3testcase.flac both file-4.16 and file-4.17 show it as: MP3 file with ID3 version 2.3.0 tag -mike From christos at zoulas.com Tue Mar 14 03:53:07 2006 From: christos at zoulas.com (Christos Zoulas) Date: Mon, 13 Mar 2006 20:53:07 -0500 Subject: misdetection of flac file w/id3 tag as mp3 In-Reply-To: <200603132006.28261.vapier@gentoo.org> from Mike Frysinger (Mar 13, 8:06pm) Message-ID: <20060314015307.CB1B756534@rebar.astron.com> On Mar 13, 8:06pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: misdetection of flac file w/id3 tag as mp3 | a Gentoo user filed Bug 124872 where they reported some of their flac files | being misreported as mp3s ... ive got an example file here: | http://wh0rd.org/flacid3testcase.flac | | both file-4.16 and file-4.17 show it as: | MP3 file with ID3 version 2.3.0 tag | -mike Here's a patch... I might re-do it later. christos Index: audio =================================================================== RCS file: /src/pub/file/magic/Magdir/audio,v retrieving revision 1.38 diff -u -u -r1.38 audio --- audio 2 Mar 2006 22:10:26 -0000 1.38 +++ audio 14 Mar 2006 01:52:26 -0000 @@ -221,9 +221,41 @@ # SGI SoundTrack 0 string _SGI_SoundTrack SGI SoundTrack project file # ID3 version 2 tags -0 string ID3 MP3 file with ID3 version 2. +0 string ID3 Audio file with ID3 version 2 >3 ubyte <0xff \b%d. >4 ubyte <0xff \b%d tag +>2584 string fLaC \b, FLAC encoding +>>2588 byte&0x7f >0 \b, unknown version +>>2588 byte&0x7f 0 \b +# some common bits/sample values +>>>2600 beshort&0x1f0 0x030 \b, 4 bit +>>>2600 beshort&0x1f0 0x050 \b, 6 bit +>>>2600 beshort&0x1f0 0x070 \b, 8 bit +>>>2600 beshort&0x1f0 0x0b0 \b, 12 bit +>>>2600 beshort&0x1f0 0x0f0 \b, 16 bit +>>>2600 beshort&0x1f0 0x170 \b, 24 bit +>>>2600 byte&0xe 0x0 \b, mono +>>>2600 byte&0xe 0x2 \b, stereo +>>>2600 byte&0xe 0x4 \b, 3 channels +>>>2600 byte&0xe 0x6 \b, 4 channels +>>>2600 byte&0xe 0x8 \b, 5 channels +>>>2600 byte&0xe 0xa \b, 6 channels +>>>2600 byte&0xe 0xc \b, 7 channels +>>>2600 byte&0xe 0xe \b, 8 channels +# some common sample rates +>>>2597 belong&0xfffff0 0x0ac440 \b, 44.1 kHz +>>>2597 belong&0xfffff0 0x0bb800 \b, 48 kHz +>>>2597 belong&0xfffff0 0x07d000 \b, 32 kHz +>>>2597 belong&0xfffff0 0x056220 \b, 22.05 kHz +>>>2597 belong&0xfffff0 0x05dc00 \b, 24 kHz +>>>2597 belong&0xfffff0 0x03e800 \b, 16 kHz +>>>2597 belong&0xfffff0 0x02b110 \b, 11.025 kHz +>>>2597 belong&0xfffff0 0x02ee00 \b, 12 kHz +>>>2597 belong&0xfffff0 0x01f400 \b, 8 kHz +>>>2597 belong&0xfffff0 0x177000 \b, 96 kHz +>>>2597 belong&0xfffff0 0x0fa000 \b, 64 kHz +>>>2601 byte&0xf >0 \b, >4G samples +>2584 string !fLaC \b, MP3 encoding # NSF (NES sound file) magic 0 string NESM\x1a NES Sound File From vapier at gentoo.org Tue Mar 14 04:03:30 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 13 Mar 2006 21:03:30 -0500 Subject: misdetection of flac file w/id3 tag as mp3 In-Reply-To: <20060314015307.CB1B756534@rebar.astron.com> References: <20060314015307.CB1B756534@rebar.astron.com> Message-ID: <200603132103.30967.vapier@gentoo.org> On Monday 13 March 2006 20:53, Christos Zoulas wrote: > On Mar 13, 8:06pm, vapier at gentoo.org (Mike Frysinger) wrote: > -- Subject: misdetection of flac file w/id3 tag as mp3 > > | a Gentoo user filed Bug 124872 where they reported some of their flac > | files being misreported as mp3s ... ive got an example file here: > | http://wh0rd.org/flacid3testcase.flac > | > | both file-4.16 and file-4.17 show it as: > | MP3 file with ID3 version 2.3.0 tag > | -mike > > Here's a patch... I might re-do it later. seems to work for me, thanks :) -mike From vapier at gentoo.org Mon Apr 10 05:03:03 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 9 Apr 2006 22:03:03 -0400 Subject: removing old bundled libtool code Message-ID: <200604092203.03516.vapier@gentoo.org> when the next release is made, could you make sure the 'ltconfig' file is removed ? newer versions of libtool no longer need/use it -mike From christos at zoulas.com Mon Apr 10 06:38:45 2006 From: christos at zoulas.com (Christos Zoulas) Date: Sun, 9 Apr 2006 23:38:45 -0400 Subject: removing old bundled libtool code In-Reply-To: <200604092203.03516.vapier@gentoo.org> from Mike Frysinger (Apr 9, 10:03pm) Message-ID: <20060410033845.944C556534@rebar.astron.com> On Apr 9, 10:03pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: removing old bundled libtool code | when the next release is made, could you make sure the 'ltconfig' file is | removed ? newer versions of libtool no longer need/use it Will do. Thanks, christos From rvokal at redhat.com Wed May 3 11:34:13 2006 From: rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) Date: Wed, 03 May 2006 10:34:13 +0200 Subject: File output on powerpoint presentation Message-ID: <1146645253.3091.21.camel@localhost.localdomain> Hi, recently I realized strange output on MS powerpoint files. When getting mine type for .ppt file I get $ file -ibk test.ppt \012- application/powerpoint\012- application/msword\012- application/msword Note the leading blank character. This breaks output of file -ib which displays nothing and ends with zero return value. Other MS documents seems to be fine, there's no leading white space and output is correct. $ file -ibk ipsec.doc application/msword\012- application/powerpoint\012- application/msword \012- application/msword I guess the leading blank is bogus. The file should continue reading other mine type when there isn't any output. Radek -- Radek Vok?l -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mx.gw.com/pipermail/file/attachments/20060503/0bdbf239/attachment.bin From christos at zoulas.com Wed May 3 15:42:02 2006 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 3 May 2006 08:42:02 -0400 Subject: File output on powerpoint presentation In-Reply-To: <1146645253.3091.21.camel@localhost.localdomain> from Radek =?ISO-8859-1?Q?Vok=E1l?= (May 3, 10:34am) Message-ID: <20060503124202.DB9D556534@rebar.astron.com> On May 3, 10:34am, rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) wrote: -- Subject: File output on powerpoint presentation | Hi, recently I realized strange output on MS powerpoint files. When | getting mine type for .ppt file I get | | $ file -ibk test.ppt | \012- application/powerpoint\012- application/msword\012- | application/msword | | Note the leading blank character. This breaks output of file -ib which | displays nothing and ends with zero return value.=20 | | Other MS documents seems to be fine, there's no leading white space and | output is correct. | | $ file -ibk ipsec.doc | application/msword\012- application/powerpoint\012- application/msword | \012- application/msword | | I guess the leading blank is bogus. The file should continue reading | other mine type when there isn't any output.=20 | | Radek Can you send me the first few k of such a powerpoint file? christos From rvokal at redhat.com Wed May 3 15:59:10 2006 From: rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) Date: Wed, 03 May 2006 14:59:10 +0200 Subject: File output on powerpoint presentation In-Reply-To: <20060503124202.DB9D556534@rebar.astron.com> References: <20060503124202.DB9D556534@rebar.astron.com> Message-ID: <1146661150.3091.28.camel@localhost.localdomain> On Wed, 2006-05-03 at 08:42 -0400, Christos Zoulas wrote: > On May 3, 10:34am, rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) wrote: > -- Subject: File output on powerpoint presentation > > | Hi, recently I realized strange output on MS powerpoint files. When > | getting mine type for .ppt file I get > | > | $ file -ibk test.ppt > | \012- application/powerpoint\012- application/msword\012- > | application/msword > | > | Note the leading blank character. This breaks output of file -ib which > | displays nothing and ends with zero return value.=20 > | > | Other MS documents seems to be fine, there's no leading white space and > | output is correct. > | > | $ file -ibk ipsec.doc > | application/msword\012- application/powerpoint\012- application/msword > | \012- application/msword > | > | I guess the leading blank is bogus. The file should continue reading > | other mine type when there isn't any output.=20 > | > | Radek > > Can you send me the first few k of such a powerpoint file? > > christos > Here you are .. Radek - Radek Vok?l -------------- next part -------------- A non-text attachment was scrubbed... Name: test.ppt Type: application/vnd.ms-powerpoint Size: 3791 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060503/cedf764c/attachment.ppt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mx.gw.com/pipermail/file/attachments/20060503/cedf764c/attachment.bin From christos at zoulas.com Wed May 3 18:10:42 2006 From: christos at zoulas.com (Christos Zoulas) Date: Wed, 3 May 2006 11:10:42 -0400 Subject: File output on powerpoint presentation In-Reply-To: <1146661150.3091.28.camel@localhost.localdomain> from Radek =?ISO-8859-1?Q?Vok=E1l?= (May 3, 2:59pm) Message-ID: <20060503151042.D889E56534@rebar.astron.com> On May 3, 2:59pm, rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) wrote: -- Subject: Re: File output on powerpoint presentation Here's a patch. Please let me know if it works for you! Thanks, christos Index: softmagic.c =================================================================== RCS file: /src/pub/file/src/softmagic.c,v retrieving revision 1.78 diff -u -u -r1.78 softmagic.c --- softmagic.c 12 Mar 2006 22:09:33 -0000 1.78 +++ softmagic.c 3 May 2006 14:55:09 -0000 @@ -53,6 +53,7 @@ const unsigned char *, size_t, size_t); private int mconvert(struct magic_set *, union VALUETYPE *, struct magic *); private int check_mem(struct magic_set *, unsigned int); +private int print_sep(struct magic_set *, int); /* * softmagic - lookup one file in database @@ -141,21 +142,20 @@ continue; } - if (!firstline) { /* we found another match */ - /* put a newline and '-' to do some simple formatting*/ - if (file_printf(ms, "\n- ") == -1) + /* + * If we are going to print something, we'll need to print + * a blank before we print something else. + */ + if (magic[magindex].desc[0]) { + need_separator = 1; + if (print_sep(ms, firstline) == -1) return -1; } if ((ms->c.off[cont_level] = mprint(ms, &p, &magic[magindex])) == -1) return -1; - /* - * If we printed something, we'll need to print - * a blank before we print something else. - */ - if (magic[magindex].desc[0]) - need_separator = 1; + /* and any continuations that match */ if (check_mem(ms, ++cont_level) == -1) return -1; @@ -189,6 +189,14 @@ break; default: /* + * If we are going to print something, + * make sure that we have a separator first. + */ + if (magic[magindex].desc[0]) { + if (print_sep(ms, firstline) == -1) + return -1; + } + /* * This continuation matched. * Print its message, with * a blank before it if @@ -249,7 +257,7 @@ mprint(struct magic_set *ms, union VALUETYPE *p, struct magic *m) { uint32_t v; - int32_t t=0 ; + int32_t t = 0; switch (m->type) { @@ -1503,3 +1511,15 @@ return matched; } + +private int +print_sep(struct magic_set *ms, int firstline) +{ + if (firstline) + return 0; + /* + * we found another match + * put a newline and '-' to do some simple formatting + */ + return file_printf(ms, "\n- "); +} From rvokal at redhat.com Tue May 9 09:32:44 2006 From: rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) Date: Tue, 09 May 2006 08:32:44 +0200 Subject: File output on powerpoint presentation In-Reply-To: <20060503151042.D889E56534@rebar.astron.com> References: <20060503151042.D889E56534@rebar.astron.com> Message-ID: <1147156364.4421.9.camel@localhost.localdomain> No, the output is still same. There's a leading space and -ib shows nothing. # file -ikb ~rvokal/work/file/LecturesPart01.ppt \012- application/msword\012- application/msword Radek On Wed, 2006-05-03 at 11:10 -0400, Christos Zoulas wrote: > On May 3, 2:59pm, rvokal at redhat.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) wrote: > -- Subject: Re: File output on powerpoint presentation > > Here's a patch. Please let me know if it works for you! > > Thanks, > > christos > > Index: softmagic.c > =================================================================== > RCS file: /src/pub/file/src/softmagic.c,v > retrieving revision 1.78 > diff -u -u -r1.78 softmagic.c > --- softmagic.c 12 Mar 2006 22:09:33 -0000 1.78 > +++ softmagic.c 3 May 2006 14:55:09 -0000 > @@ -53,6 +53,7 @@ > const unsigned char *, size_t, size_t); > private int mconvert(struct magic_set *, union VALUETYPE *, struct magic *); > private int check_mem(struct magic_set *, unsigned int); > +private int print_sep(struct magic_set *, int); > > /* > * softmagic - lookup one file in database > @@ -141,21 +142,20 @@ > continue; > } > > - if (!firstline) { /* we found another match */ > - /* put a newline and '-' to do some simple formatting*/ > - if (file_printf(ms, "\n- ") == -1) > + /* > + * If we are going to print something, we'll need to print > + * a blank before we print something else. > + */ > + if (magic[magindex].desc[0]) { > + need_separator = 1; > + if (print_sep(ms, firstline) == -1) > return -1; > } > > if ((ms->c.off[cont_level] = mprint(ms, &p, &magic[magindex])) > == -1) > return -1; > - /* > - * If we printed something, we'll need to print > - * a blank before we print something else. > - */ > - if (magic[magindex].desc[0]) > - need_separator = 1; > + > /* and any continuations that match */ > if (check_mem(ms, ++cont_level) == -1) > return -1; > @@ -189,6 +189,14 @@ > break; > default: > /* > + * If we are going to print something, > + * make sure that we have a separator first. > + */ > + if (magic[magindex].desc[0]) { > + if (print_sep(ms, firstline) == -1) > + return -1; > + } > + /* > * This continuation matched. > * Print its message, with > * a blank before it if > @@ -249,7 +257,7 @@ > mprint(struct magic_set *ms, union VALUETYPE *p, struct magic *m) > { > uint32_t v; > - int32_t t=0 ; > + int32_t t = 0; > > > switch (m->type) { > @@ -1503,3 +1511,15 @@ > > return matched; > } > + > +private int > +print_sep(struct magic_set *ms, int firstline) > +{ > + if (firstline) > + return 0; > + /* > + * we found another match > + * put a newline and '-' to do some simple formatting > + */ > + return file_printf(ms, "\n- "); > +} > > _______________________________________________ > File mailing list > File at mx.gw.com > http://mx.gw.com/mailman/listinfo/file -- Radek Vok?l -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mx.gw.com/pipermail/file/attachments/20060509/4d200e5a/attachment.bin From vapier at gentoo.org Fri May 26 06:29:31 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 25 May 2006 23:29:31 -0400 Subject: [patch] detect blackfin elf objects Message-ID: <200605252329.35018.vapier@gentoo.org> simple patch to detect blackfin type ELF objects: $ bfin-elf-gcc -c test.c $ file test.o test.o: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYSV), not stripped -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060525/296aef4f/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: file-blackfin.patch Type: text/x-diff Size: 307 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060525/296aef4f/attachment-0001.bin From vapier at gentoo.org Fri May 26 06:23:09 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 25 May 2006 23:23:09 -0400 Subject: [patch] update magic files for processors Renesas bought from Hitachi Message-ID: <200605252323.12903.vapier@gentoo.org> Renesas bought the SuperH line of cpu's as well as the H8 a while back, but `file` still reports Hitachi ... patch attached -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060525/2bdeaad5/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: file-renesas-bought-superh.patch Type: text/x-diff Size: 2928 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060525/2bdeaad5/attachment-0001.bin From christos at zoulas.com Fri May 26 15:16:06 2006 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 26 May 2006 08:16:06 -0400 Subject: [patch] detect blackfin elf objects In-Reply-To: <200605252329.35018.vapier@gentoo.org> from Mike Frysinger (May 25, 11:29pm) Message-ID: <20060526121606.1DAA356534@rebar.astron.com> On May 25, 11:29pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: [patch] detect blackfin elf objects | simple patch to detect blackfin type ELF objects: | $ bfin-elf-gcc -c test.c | $ file test.o | test.o: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYS= | V),=20 | not stripped | =2Dmike Thanks a lot. christos From christos at zoulas.com Fri May 26 15:17:46 2006 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 26 May 2006 08:17:46 -0400 Subject: [patch] update magic files for processors Renesas bought from Hitachi In-Reply-To: <200605252323.12903.vapier@gentoo.org> from Mike Frysinger (May 25, 11:23pm) Message-ID: <20060526121746.BC40856534@rebar.astron.com> On May 25, 11:23pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: [patch] update magic files for processors Renesas bought from Hit | Renesas bought the SuperH line of cpu's as well as the H8 a while back, but | | `file` still reports Hitachi ... patch attached | mike Thanks a lot! christos From vapier at gentoo.org Sun Jul 30 20:12:36 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 30 Jul 2006 13:12:36 -0400 Subject: [patch] fix detecting of jffs2 and u-boot images Message-ID: <200607301312.37049.vapier@gentoo.org> jffs2 uses just 0x1985 as the magic number ... i dont know why file currently tries to also match 0xe001 or what that's for, but the latest mkfs.jffs2 binary uses 0x2003 (or something, i forget exactly) ... the kernel itself doesnt care, so i dont think file should care either :) the PPCBoot project is dead now as it has merged with ARMBoot and formed the basis of u-boot ... so ive updated the output to say "u-boot image" instead of "PPCBoot image" -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060730/b854bb4f/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: file-uboot-jffs2.patch Type: text/x-diff Size: 807 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20060730/b854bb4f/attachment-0001.bin From christos at zoulas.com Sun Jul 30 22:08:32 2006 From: christos at zoulas.com (Christos Zoulas) Date: Sun, 30 Jul 2006 15:08:32 -0400 Subject: [patch] fix detecting of jffs2 and u-boot images In-Reply-To: <200607301312.37049.vapier@gentoo.org> from Mike Frysinger (Jul 30, 1:12pm) Message-ID: <20060730190832.290F9565EC@rebar.astron.com> On Jul 30, 1:12pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: [patch] fix detecting of jffs2 and u-boot images | jffs2 uses just 0x1985 as the magic number ... i dont know why file current= | ly=20 | tries to also match 0xe001 or what that's for, but the latest mkfs.jffs2=20 | binary uses 0x2003 (or something, i forget exactly) ... the kernel itself=20 | doesnt care, so i dont think file should care either :) | | the PPCBoot project is dead now as it has merged with ARMBoot and formed th= | e=20 | basis of u-boot ... so ive updated the output to say "u-boot image" instead= | =20 | of "PPCBoot image" | =2Dmike | Thanks a lot. christos From vapier at gentoo.org Thu Oct 19 06:21:41 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 18 Oct 2006 23:21:41 -0400 Subject: segfault in file-4.17 when detecting EMF Message-ID: <200610182321.42076.vapier@gentoo.org> i tried looking into this, but i cant seem to track it down ... the attached file makes `file` segfault on x86 might i suggest a sanity check in mcopy() that makes sure s+offset doesnt overflow and thus is not smaller than src (patch attached) -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20061018/57331d9e/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: file-sanity-check-mcopy.patch Type: text/x-diff Size: 323 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20061018/57331d9e/attachment-0001.bin -------------- next part -------------- Hello EMF nation:) It was great to meet EMF members from Ireland and Columbia in Chicago - what a blast. FAVOR : Please sign your e-mails with your name and country (at the minimum). This will help us with the research that we are conducting. Thanks... Also, if you are interested in IXMA and the Brand Week opportunity, but haven't e-mailed me yet - please do! My love to all EMF nationals:) [Name Removed] From christos at zoulas.com Tue Oct 31 22:24:50 2006 From: christos at zoulas.com (Christos Zoulas) Date: Tue, 31 Oct 2006 15:24:50 -0500 Subject: file-4.18 is now available Message-ID: <20061031202450.5E6FA56407@rebar.astron.com> Many fixes since the last release! ftp://ftp.astron.com/pub/file/file-4.18.tar.gz Enjoy, christos 2006-10-31 15:14 Christos Zoulas * Check offset before copying (Mike Frysinger) * merge duplicated code * add quad date support * make sure that we nul terminate desc (Ryoji Kanai) * don't process elf notes multiple times * allow -z to report empty compressed files * use calloc to initialize the ascii buffers (Jos van den Oever) 2006-06-08 11:11 Christos Zoulas * QNX fixes (Mike Gorchak) * Add quad support. * FIFO checks (Dr. Werner Fink) * Linux ELF fixes (Dr. Werner Fink) * Magic format checks (Dr. Werner Fink) * Magic format function improvent (Karl Chen) 2006-05-03 11:11 Christos Zoulas * Pick up some elf changes and some constant fixes from SUSE * Identify gnu tar vs. posix tar * When keep going, don't print spurious newlines (Radek Vok?l) 2006-04-01 12:02 Christos Zoulas * Use calloc instead of malloc (Mike Frysinger) * Fix configure script to detect wctypes.h (Mike Frysinger) From vapier at gentoo.org Tue Oct 31 22:36:53 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 31 Oct 2006 15:36:53 -0500 Subject: file-4.18 is now available In-Reply-To: <20061031202450.5E6FA56407@rebar.astron.com> References: <20061031202450.5E6FA56407@rebar.astron.com> Message-ID: <200610311536.54107.vapier@gentoo.org> On Tuesday 31 October 2006 15:24, Christos Zoulas wrote: > Many fixes since the last release! this one doesnt compile for me on amd64 :( done >> magic ../src/file -C -m magic lt-file: magic element size 136 != 128 make[2]: *** [magic.mgc] Error 255 -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://mx.gw.com/pipermail/file/attachments/20061031/e6d1c1f4/attachment.bin From christos at zoulas.com Tue Oct 31 22:41:01 2006 From: christos at zoulas.com (Christos Zoulas) Date: Tue, 31 Oct 2006 15:41:01 -0500 Subject: file-4.18 is now available In-Reply-To: <200610311536.54107.vapier@gentoo.org> from Mike Frysinger (Oct 31, 3:36pm) Message-ID: <20061031204101.2746956407@rebar.astron.com> On Oct 31, 3:36pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: Re: file-4.18 is now available | this one doesnt compile for me on amd64 :( | done >> magic | ../src/file -C -m magic | lt-file: magic element size 136 != 128 | make[2]: *** [magic.mgc] Error 255 | -mike Let me find an amd64 machine :-( christos From christos at zoulas.com Tue Oct 31 23:26:13 2006 From: christos at zoulas.com (Christos Zoulas) Date: Tue, 31 Oct 2006 16:26:13 -0500 Subject: file-4.18 is now available In-Reply-To: <200610311536.54107.vapier@gentoo.org> from Mike Frysinger (Oct 31, 3:36pm) Message-ID: <20061031212613.E63F856539@rebar.astron.com> On Oct 31, 3:36pm, vapier at gentoo.org (Mike Frysinger) wrote: -- Subject: Re: file-4.18 is now available | this one doesnt compile for me on amd64 :( | done >> magic | ../src/file -C -m magic | lt-file: magic element size 136 != 128 | make[2]: *** [magic.mgc] Error 255 | -mike New tar file in the same place. christos From christos at zoulas.com Tue Dec 12 18:44:37 2006 From: christos at zoulas.com (Christos Zoulas) Date: Tue, 12 Dec 2006 11:44:37 -0500 Subject: file-4.19 is now available Message-ID: <20061212164437.4B18C56539@rebar.astron.com> >From ftp://ftp.astron.com/pub/file/file-4.19.tar.gz Fixes: 2006-12-11 16:49 Christos Zoulas * fix byteswapping issue * report the number of bytes we tried to allocate when allocation fails * add a few missed cases in the strength routine 2006-12-08 16:32 Christos Zoulas * store and print the line number of the magic entry for debugging. * if the magic entry did not print anything, don't treat it as a match * change the magic strength algorithm to take into account the relationship op. * fix a bug in search where we could accidentally return a match. * propagate the error return from match to file_softmagic. 2006-11-25 13:35 Christos Zoulas * Don't store the current offset in the magic struct, because it needs to be restored and it was not done properly all the time. Bug found by: Arkadiusz Miskiewicz * Fix problem in the '\0' separator; and don't print it as an additional separator; print it as the only separator. 2006-11-17 10:51 Christos Zoulas * Added a -0 option to print a '\0' separator Etienne Buira