Bug 174665

Summary: mkisofs produces erroneous "Unknown file type (unallocated)" warning
Product: [Fedora] Fedora Reporter: JW <ohtmvyyn>
Component: cdrtoolsAssignee: Harald Hoyer <harald>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-12-01 09:14:14 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:

Description JW 2005-12-01 08:57:16 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:
Always

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

Actual Results:  Unknown file type (unallocated) /u/backup.monthly/.. - ignoring and continuing.

Expected Results:  No output


Additional info:

Comment 1 JW 2005-12-01 09:14:14 UTC

*** This bug has been marked as a duplicate of 174667 ***