From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217 Description of problem: This version of file produces some really stupid output. It is also inconsistent with previous behavior and therefore breaks all sorts of scripts. Version-Release number of selected component (if applicable): file-4.15-fc4.1 How reproducible: Always Steps to Reproduce: 1.dd if=/dev/zero ibs=512 count=1 of=tst 2.file tst 3. Actual Results: tst: Expected Results: tst: data Additional info:
file-4.16-fc4.1 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
(In reply to comment #1) > file-4.16-fc4.1 has been pushed for FC4, which should resolve this issue. If > these problems are still present in this version, then please make note of it in > this bug report. > Tested against file-4.16-fc4.1 and is still a problem. 1. dd ibs=512 count=10 if=/dev/zero of=tst 2. file tst Instead of output "tst: data" get just "tst:" as before.
And this is also for you. root@gigolo ~# rpm -q file file-4.16-fc4.1 root@gigolo ~# file /var/lib/rpm/Basenames /var/lib/rpm/Basenames: Berkeley DB (Hash, version 8, native byte-order) root@gigolo ~# dd ibs=512 count=10 if=/dev/zero of=tst 10+0 records in 10+0 records out root@gigolo ~# file ./tst ./tst: data so I'm not sure against what are you testing this problem but I see it fixed.
> so I'm not sure against what are you testing this problem but I see it fixed. Well it appears to you to be fixed because a new error has been introduced into the cracklib portion of magic. This new error masks the error which I gave a patch for. The latter portion of the cracklib section used to look like this: 0 long 0 4 belong 0x70775631 Cracklib password index, big endian ("64-bit") >12 belong >0 (%i words) But instead of changing the ">12" to ">>12" sombody has gone and deleted the first line. That means that this will never match anything because probably no file will ever begin with "31 56 77 70 31 56 77 70". So because of that error on top of errors matching continues down to the Berkeley stuff. What has really happened is that somebody was trying to create a rule for 64-bit cracklib database index. There isn't, unfortunately, a "belonglong" type (there should be), and you cannot achieve that effect by using the two lines in the above sample. Because the first line might match without any subsequent line matching which will mean the search is over and a blank line will be output. So my patch was wrong, and somebody else did the wrong fix. So we are both equally as incompetent as each other. Anyhow the real fix, until a belonglong type is added, is to change the three lines to: 0 string \0\0\0\0\x31\x56\x77\x70 Cracklib password index, big endian ("64-bit") >12 belong >0 (%i words) It is ugly, but it is correct.
*** Bug 174139 has been marked as a duplicate of this bug. ***
When I said correct I really meant "more-or-less correct". The string should probably be "\0\0\0\0\x70\x77\x56\x31" because it is supposed to be big-endian.
Sorry, but I lost the focus somehow. Why do you think that Basenames should be recognized as cracklib file? I've just tested cracklib index files, on 64 bit and 32bit machine, the output looks fine. on my x86_64 box /usr/share/cracklib/pw_dict.pwi: Cracklib password index, little endian (1692953 words) and my i686 machine shows /usr/share/cracklib/pw_dict.pwi: Cracklib password index, little endian (49613 words)
(In reply to comment #7) > Sorry, but I lost the focus somehow. My lips are sealed. > Why do you think that Basenames should be > recognized as cracklib file? I don't and I never have thing that it *should*! Originally, before the bad fixup, it was. After the bad fixup it isn't but because of bad fixup. > I've just tested cracklib index files, on 64 > bit and 32bit machine, the output looks fine. > > on my x86_64 box > /usr/share/cracklib/pw_dict.pwi: Cracklib password index, little endian (1692953 > words) > > and my i686 machine shows > /usr/share/cracklib/pw_dict.pwi: Cracklib password index, little endian (49613 > words) > Please read comment #4 carefully!
It seems that in 4.17 it is fixed now. Can you check it up? In the cracklib part of magic is no longer the row with empty string (0 long 0). The 64-bit cracklib part looks like this. # really bellong 0x0000000070775631 4 belong 0x70775631 Cracklib password index, big endian ("64-bit") >12 belong >0 (%i words) It seems ok now despite it does not take care of first 4 bytes. The zero filled file is also recognized as "data" now. Do you find it working or am I missing something?