Bug 174667 - mkisofs produces erroneous "Unknown file type (unallocated)" warning
Summary: mkisofs produces erroneous "Unknown file type (unallocated)" warning
Alias: None
Product: Fedora
Classification: Fedora
Component: cdrkit
Version: 13
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Honza Horak
QA Contact: Fedora Extras Quality Assurance
: 174665 191860 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-12-01 09:12 UTC by JW
Modified: 2011-02-28 10:55 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 193916 (view as bug list)
Last Closed: 2011-02-16 13:48:10 UTC

Attachments (Terms of Use)
proposed patch (1.10 KB, patch)
2011-01-25 13:32 UTC, Honza Horak
no flags Details | Diff

Description JW 2005-12-01 09:12:05 UTC
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:
When running mkisfs sometimes you might get error such as:

    Unknown file type (unallocated) /some/path/.. - ignoring and continuing.

To reliably reproduce this bug you need to create a directory such that the ".." directory entry preceeds the "." directory entry when opendir()/readdir() runs. Quite frankly I don't know how you can go about achieving this. All I know is that I have one such directory and mkisofs code depends on it discovering the "." entry before the ".." entry (because when mkisofs encounters the ".." entry it switches its lstatbuf with that which was saved from the "." entry - see mkisofs/tree.c).

Version-Release number of selected component (if applicable):
mkisofs-2.01.1-9.0.FC4.1  cdrtools-2.01.1-9.0.FC4.1

How reproducible:

Steps to Reproduce:
1.Create directory /some/path with ".." having directory slot before "." entry
2.mkisofs -o /dev/null /some/path

Actual Results:  Unknown file type (unallocated) /some/path/.. - ignoring and continuing.

Expected Results:  No output

Additional info:

Comment 1 JW 2005-12-01 09:14:17 UTC
*** Bug 174665 has been marked as a duplicate of this bug. ***

Comment 2 JW 2006-04-19 11:43:33 UTC
Perhaps somebody might explain why this ticket suddenly closed itself a few
minutes ago.  I certainly didn't.

Why wont the bug be fixed?

Comment 3 Harald Hoyer 2006-04-19 16:43:30 UTC
I see the bug, but I wont fix this. Please report this bug to the author of
mkisofs. The fix would need some more changes, than I am willing to patch in
every version.

Comment 4 Harald Hoyer 2006-06-06 06:20:17 UTC
*** Bug 191860 has been marked as a duplicate of this bug. ***

Comment 5 Harald Hoyer 2006-06-14 12:10:10 UTC
Please try the mkisofs test rpms from

Comment 6 Philip Prindeville 2006-06-14 14:52:22 UTC
Will this be compatible with FC5?

And has everyone that has seen this bug experienced it with LVM?  Or did anyone
see it on ext2/ext3 filesystems?

Comment 7 JW 2006-06-14 15:07:34 UTC
(In reply to comment #6)
> Or did anyone see it on ext2/ext3 filesystems?

It happens for me on a plain 100GB ext3 filesystem.
It would seem that the directory entries get hashed under certain conditions
(filesystem size?) so the order of entries cannot be guaranteed.  But mkisofs
assumes a certain ordering of entries.

Comment 8 Christian Iseli 2007-01-22 11:03:05 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?


Comment 9 JW 2007-01-22 11:08:04 UTC
applicable to FC7

Comment 10 Stepan Kasal 2010-01-14 13:05:10 UTC
The bug is back, at least in current rawhide.
The package changed name from cdrtools to cdrkit, the patch proposed in bug #193916 would cleanly apply, but it was lost in the translation.

Please apply patch from attachment #311798 [details] to cdrkit

Comment 11 Jörg Schilling 2010-01-14 14:06:48 UTC
It is most unlikely that this patch will fix the problem
as the patch is not related to the reported problem. It
may be that the patch under some circumstances hides the 
problem (which is a different thing).

A correct solution has been implemented many years ago in
the original software (in fact a short time only after the 
problem has been reported).

Get the original software from:


Comment 12 Bug Zapper 2010-03-15 11:49:40 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:

Comment 13 Fedora Admin XMLRPC Client 2011-01-10 13:23:38 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 14 Honza Horak 2011-01-25 13:32:05 UTC
Created attachment 475171 [details]
proposed patch

I've prepared a patch for the current version (F14 or Rawhide), similar to patch used to resolve bug 193916, but a little modified from attachment #311798 [details] (it is outdated).

Unfortunately, I'm not able to reproduce the error (I'm not able to find a directory, where ".." entry precedes "." entry). 

Can anybody try the attached patch? Or is there any guaranteed way how to create a directory, where ".." entry precedes "." entry?

Comment 15 Jörg Schilling 2011-01-25 14:31:22 UTC
The original mkisofs does not have this problem. 

Why do you like to work on a completely broken Debian variant when the well maintained original is available?

Comment 16 JW 2011-01-27 23:06:08 UTC
Jan Horak, if you read my original post you will discover that I said " don't know how you can go about achieving this".  So I don't quite understand why you are asking me for information that I have already stated that I cannot provide.

Anyhow my best guess is that it was created using the "-O dir_index" option of mke2fs.

I suggest that you create a new filesystem on a device (or a plain file for loop mounting) using the "-O dir_index" feature. Then create some files on it.

And to check that you have created what you are looking for use perl's opendir/readdir.

To Jorg Schilling, on 1st Dec 2005 you stated in an email to me regarding this problem:

> Well simple: All FS implementations on UNIX that do return '.' and '..'
at all return them first and in this order.....
> ...
> Any UNIX guru would cuncur me.....

Then on 5th Dec 2005 you told me:

> Note that the extstence of physical '.' and '..' entries in adirectory
could be called a severe UNIX design bug.
> ...
> Decent filesystem implementeation don't have them and just fake their
existence for stat(), open() and similar.

And so on and so on.  You have always denied the possibility of "." and ".." returning in a random order.  And I doubt that you have tested for this situation.

Comment 17 Jörg Schilling 2011-01-31 14:22:53 UTC
Just because a UNIX compatible system cannot deliver '.' and '..' entries after other directory entries and just because I am not aware of a proof for such behavior.... This does not mean I am not able to create a simulation environment to create a workaround.

The mkisofs sources have been seen a major rework in summer 2006 and since then, mkisofs is able to deal with such file systems.

genisoimage on the other side is unmaintained since May 2007. Do not expect any help with genisoimage.

Comment 18 Honza Horak 2011-02-02 14:02:19 UTC
JW, thanks for your comment, I'm able to reproduce this bug now. I've created a new partition using "mke2fs -O dir_index" command and I've really got the warning, but only when using very old version of genisoimage/mkisofs.

However, the bug is not present in recent versions of genisoimage, so I will close this bug soon.

Nevertheless, the proposed patch will be applied, because it wasn't done when fixing in RHEL and it fixes another issue as well.

Comment 19 JW 2011-02-02 14:08:43 UTC
Well, the bug was opened in 2005.  That is 6 years ago.  So no surprise then that the warning is only found in a "very old version".

Comment 20 Jörg Schilling 2011-02-16 13:59:47 UTC
Given the fact that genisoimage has no active development sice 4 years, I am surprised to read that this bug ha been fixed.

The related problem has been fixed for mkisofs in August 2006 together with many other bugs that are still present in genisoimage.

Comment 21 Fedora Update System 2011-02-28 10:55:53 UTC
Package cdrkit-1.1.11-4.fc15:
* should fix your issue,
* was pushed to the Fedora 15 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cdrkit-1.1.11-4.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).

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