Bug 1263599 - The command "genisoimage" generates empty output if one of the pathspecs does not exist
The command "genisoimage" generates empty output if one of the pathspecs does...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cdrkit (Show other bugs)
25
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Frantisek Kluknavsky
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-16 05:21 EDT by Joachim Backes
Modified: 2017-01-04 11:35 EST (History)
8 users (show)

See Also:
Fixed In Version: cdrkit-1.1.11-32.fc26
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-04 11:35:39 EST
Type: Bug
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 Joachim Backes 2015-09-16 05:21:25 EDT
Description of problem:
Using genisoimage with a list of pathspecs: xxxxx and yyyyy

The problem: xxxxx exists, but yyyyy does not exist.

If running

genisoimage -R -T -J -l -allow-leading-dots -V "EST2014" -graft-points -o - xxxxx  yyyyy >~/iso


then ~/iso will be generated, but it's empty! Only if all pathspecs are available, then the generated output iso file will not be empty.

But  the manpage says that genisoimage will "merge the files found in all of the specified path components":

"pathspec  is  the  path  of  the  directory  tree to be copied into the
ISO9660 filesystem.  Multiple paths can be specified,  and  genisoimage
will  merge  the files found in all of the specified path components to
form the filesystem image"

So genisoimage should at least use the file xxxxx for generating the iso image!


Version-Release number of selected component (if applicable):
genisoimage-1.1.11-29.fc23.x86_64

How reproducible:
always

Steps to Reproduce:
1.

ls -l xxxxx yyyyy
ls: cannot access yyyyy: No such file or directory
-rw-rw-r-- 1 backes backes 3076096 Sep 16 10:55 xxxxx

2.

genisoimage -R -T -J -l -allow-leading-dots -V "EST2014" -graft-points -o - xxxxx  yyyyy >~/iso


3.

Actual results:

Warning: creating filesystem that does not conform to ISO-9660.
I: -input-charset not specified, using utf-8 (detected in locale settings)
genisoimage: No such file or directory. Invalid node - 'yyyyy'.

ls -l ~/iso
-rw-rw-r-- 1 backes backes 0 Sep 16 11:10 /home/backes/iso

Expected results:
No image with zero length!

Additional info:

If using the command with only xxxxx as pathspec, then one will get a correct output file:

genisoimage -R -T -J -l -allow-leading-dots -V "EST2014" -graft-points -o - xxxxx   >~/iso

Warning: creating filesystem that does not conform to ISO-9660.
I: -input-charset not specified, using utf-8 (detected in locale settings)
Total translation table size: 217
Total rockridge attributes bytes: 327
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
1684 extents written (3 MB)


ls -l ~/iso
-rw-rw-r-- 1 backes backes 3448832 Sep 16 11:11 /home/backes/iso
Comment 1 Kamil Dudka 2015-09-16 06:13:17 EDT
I fail to see how this bug is related to coreutils, switching the component to cdrkit..
Comment 2 Joachim Backes 2015-09-16 07:15:59 EDT
(In reply to Kamil Dudka from comment #1)
> I fail to see how this bug is related to coreutils, switching the component
> to cdrkit..

I know, but in F23, there is no pkg called cdrkit (as previously) :-)
Comment 3 Kamil Dudka 2015-09-16 07:26:39 EDT
The source package is called cdrkit.  Several sub-packages are built out of it:

http://koji.fedoraproject.org/koji/buildinfo?buildID=647611

There are no components for sub-packages of Fedora packages in Bugzilla, so you have to look up the corresponding SRPM in case the mapping is not clear.
Comment 4 Frantisek Kluknavsky 2015-09-16 08:58:05 EDT
Hi,

yes, genisoimage behaves as you describe, according to good principles of API design: do not hide problems, do not produce dubious results, report error if you can not fulfil user's explicit commands.

Imagine if genisoimage behaved as you want: Something in Fedora infrastructure goes wrong (can happen anytime), a directory is missing, but genisoimage happily creates an ISO. If it is something important, QA will catch it later. If it is something less obvious, we will distribute damaged media. The same applies for any automated deployment. The sooner an error is detected, the better.

The man page is ambiguous, I will clarify it. Thank you for noticing.
Comment 5 Joachim Backes 2015-09-16 09:10:23 EDT
(In reply to Frantisek Kluknavsky from comment #4)
> Hi,
> 
> yes, genisoimage behaves as you describe, according to good principles of
> API design: do not hide problems, do not produce dubious results, report
> error if you can not fulfil user's explicit commands.
> 
> Imagine if genisoimage behaved as you want: Something in Fedora
> infrastructure goes wrong (can happen anytime), a directory is missing, but
> genisoimage happily creates an ISO. If it is something important, QA will
> catch it later. If it is something less obvious, we will distribute damaged
> media. The same applies for any automated deployment. The sooner an error is
> detected, the better.

From my point of view, one could issue some warnings about files which cannot be included, but generate the iso nevertheless if at least 1 pathspec is available.

Or: use some ENV variable/some additional option controlling the behaviour if some error occurs as in my described case. The default behaviour could remain as it is, so the behaviour in case of Fedora isos could be unchanged. 
> 
> The man page is ambiguous, I will clarify it. Thank you for noticing.
OK
Comment 6 Fedora End Of Life 2016-11-24 07:30:54 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 7 Frantisek Kluknavsky 2017-01-04 11:35:39 EST
Man page clarified.
As sad as it might be, I am not going to become new upstream and maintain a fork with different behavior. Doubly so if current behavior is not obviously wrong, more like a matter of preference.

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