Bug 174137

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?