Bug 491596 - libmagic does not recognize pcf.gz files as font files
Summary: libmagic does not recognize pcf.gz files as font files
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F11Target 491510
TreeView+ depends on / blocked
Reported: 2009-03-23 08:40 UTC by Nicolas Mailhot
Modified: 2009-03-23 15:44 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 491510
Last Closed: 2009-03-23 15:44:11 UTC
Type: ---

Attachments (Terms of Use)
Plug fd leak from pipe() (310 bytes, patch)
2009-03-23 11:55 UTC, Panu Matilainen
no flags Details | Diff

Description Nicolas Mailhot 2009-03-23 08:40:22 UTC
libmagic does not recognize pcf.gzfiles as font files

This is necessary for font autoprovides to work with pcf.gz files


+++ This bug was initially created as a clone of Bug #491510 +++

The new font autoprovides are working well for some font formats but are not processing others:
1. ttc files: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1026593
2. pfa files: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1126190
3. compressed pcf fonts: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1054305
(and probably plain pcf fonts though I could not locate a pcf package that was properly converted yet)

--- Additional comment from nicolas.mailhot@laposte.net on 2009-03-22 08:52:40 EDT ---

Also, it seems to fail even for plain ttf files, when they have a space in their name: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1055798

--- Additional comment from pmatilai@redhat.com on 2009-03-23 02:28:14 EDT ---

The problem with .ttc and .pfa is that neither is seen as font data by libmagic:
[pmatilai@localhost cjkuni-ukai-fonts-0.2.20080216.1]$ file ukai.ttc 
ukai.ttc: data
[pmatilai@localhost culmus-0.102]$ file YehudaCLM-Bold.pfa
YehudaCLM-Bold.pfa: PostScript document text

These should be treated filed against "file" (libmagic), rpm will recognize them as fonts as soon as libmagic does.

Compressed files aren't currently being looked into. I initially enabled it when enabling the font provide stuff but it blew up at least openoffice.org build due to leaking file descriptors someplace (probably libmagic but haven't had a chance to look at it).

Spaces in filenames causing issues is likely to be something entirely different, lets not pile things up.

--- Additional comment from nicolas.mailhot@laposte.net on 2009-03-23 04:31:25 EDT ---

Ok, let's split this

Comment 1 Panu Matilainen 2009-03-23 10:09:39 UTC
To be exact, the issue here is that libmagic does recognize pcf.gz files correctly *if* MAGIC_COMPRESS flag is used, but the last I tried it in early February caolan said he started getting "cannot create pipe (Too many open files)" errors from magic_file() from within rpm on openoffice.org build.
Didn't have a chance to investigate properly at that time so I just flipped it back to not using MAGIC_COMPRESS which "fixed" the issue.

Looking it a bit more now, it seems that it's .zip files which cause fd leakage in libmagic (4.x and 5.0), other forms of compression seem to be ok. I should have a reproducer case for you shortly..

Comment 2 Panu Matilainen 2009-03-23 11:55:42 UTC
Created attachment 336274 [details]
Plug fd leak from pipe()

Ok, the issue is easily reproducable with just file(1) itself, any .zip file seems to do and run "valgrind --track-fds=yes file -z <zipfile>". 

For example:
[pmatilai@localhost ~]$ valgrind --track-fds=yes file -z /usr/lib64/openoffice.org/basis3.0/share/config/images.zip
==11616== Memcheck, a memory error detector.
==11616== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==11616== Using LibVEX rev 1884, a library for dynamic binary translation.
==11616== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==11616== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==11616== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==11616== For more details, rerun with: -v
/usr/lib64/openoffice.org/basis3.0/share/config/images.zip: PNG image, 16 x 16, 8-bit/color RGBA, non-interlaced (Zip archive data, at least v2.0 to extract)
==11616== FILE DESCRIPTORS: 4 open at exit.
==11616== Open file descriptor 4:
==11616==    at 0x3E20AD8BD7: pipe (in /lib64/libc-2.9.so)
==11616==    by 0x4C2F882: file_zmagic (compress.c:383)
==11616==    by 0x4C34DA3: file_buffer (funcs.c:206)
==11616==    by 0x4C272C6: file_or_fd (magic.c:357)
==11616==    by 0x401228: process (file.c:431)
==11616==    by 0x401CDB: main (file.c:343)

The attached one-liner seems to be sufficient to fix, but check by yourself, I'm recovering from a nasty stomach flu and not feeling exactly bright and sharp atm...

Comment 3 Daniel Novotny 2009-03-23 12:58:29 UTC
hello Panu, thanks for the patch, I checked it and it seems to work; if I add it to the next rawhide build of libmagic, can I close this bug as RAWHIDE?

Comment 4 Panu Matilainen 2009-03-23 14:18:52 UTC
Just toss this back to rpm once libmagic is fixed, I'll still need to enable the compress bit on rpm side of things before this is resolved.

Comment 5 Daniel Novotny 2009-03-23 14:35:43 UTC
OK, the patch is added in file-5.00-5.fc11, so I'll reassign this...

Comment 6 Panu Matilainen 2009-03-23 15:44:11 UTC
Okay, looking into compressed files re-enabled in rpm-4.7.0-0.beta1.6.fc11.

Thanks Daniel for fixing these so quickly.

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