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
I fail to see how this bug is related to coreutils, switching the component to cdrkit..
(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) :-)
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.
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.
(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
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.
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.