Bug 174667
| Summary: | mkisofs produces erroneous "Unknown file type (unallocated)" warning | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | JW <ohtmvyyn> | ||||
| Component: | cdrkit | Assignee: | Honza Horak <hhorak> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 13 | CC: | hhorak, kasal, npajkovs, philipp, rrakus, schily | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 193916 (view as bug list) | Environment: | |||||
| Last Closed: | 2011-02-16 13:48:10 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
*** Bug 174665 has been marked as a duplicate of this bug. *** Perhaps somebody might explain why this ticket suddenly closed itself a few minutes ago. I certainly didn't. Why wont the bug be fixed? 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. *** Bug 191860 has been marked as a duplicate of this bug. *** Please try the mkisofs test rpms from http://people.redhat.com/harald/downloads/cdrtools/2.01.1-9.0.FC4.2/ 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? (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. 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 ? Thanks. applicable to FC7 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 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: ftp://ftp.berlios.de/pub/cdrecord/alpha/ http://cdrecord.berlios.de/ 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. 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? 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? 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. 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. 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. 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". 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. 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: https://admin.fedoraproject.org/updates/cdrkit-1.1.11-4.fc15 then log in and leave karma (feedback). |
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: Always Steps to Reproduce: 1.Create directory /some/path with ".." having directory slot before "." entry 2.mkisofs -o /dev/null /some/path 3. Actual Results: Unknown file type (unallocated) /some/path/.. - ignoring and continuing. Expected Results: No output Additional info: