Bug 174137 - No output instead of "data"
No output instead of "data"
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: file (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Martin Bacovsky
:
: 174139 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-24 19:38 EST by JW
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-26 09:05:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description JW 2005-11-24 19:38:36 EST
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:
Comment 1 Radek Vokal 2005-11-28 18:17:44 EST
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.

Comment 2 JW 2005-11-28 20:44:20 EST
(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.




Comment 3 Radek Vokal 2005-11-29 02:00:52 EST
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.
Comment 4 JW 2005-11-29 03:04:49 EST
> 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.
Comment 5 JW 2005-11-29 03:12:23 EST
*** Bug 174139 has been marked as a duplicate of this bug. ***
Comment 6 JW 2005-11-29 05:28:57 EST
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.
Comment 7 Radek Vokal 2005-12-14 09:20:45 EST
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)


Comment 8 JW 2005-12-14 18:18:26 EST
(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!
Comment 9 Martin Bacovsky 2006-08-23 13:06:56 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.