Confirmed that previous version of brasero yields correct permissions.

Downgraded to:

brasero-2.28.3-6.el6.x86_64.rpm
brasero-libs-2.28.3-6.el6.x86_64.rpm
brasero-nautilus-2.28.3-6.el6.x86_64.rpm

Re-spun same disc with same data using Gnome CD/DVD Creator (brasero-nautilus).

Execute permissions correctly assigned:

[cwebster@klink ~]$ cd /media/CymSTAR_Linux_Support/
[cwebster@klink CymSTAR_Linux_Support]$ ls -l scripts/
total 50
-r-xr-xr-x. 1 cwebster cwebster  457 Jun  4  2015 cleanup_packages
-r-xr-xr-x. 1 cwebster cwebster 6962 Jun  4  2015 fix_eth_devs.py
-r-xr-xr-x. 1 cwebster cwebster 1790 Mar  3 15:42 install_audioscience
...
-r-xr-xr-x. 1 cwebster cwebster  863 Jun 11 12:33 setup_shutdownFlarbs
-r-xr-xr-x. 1 cwebster cwebster 1692 Jun  4  2015 setup_ssh
-r-xr-xr-x. 1 cwebster cwebster  252 Jun  4  2015 setup_svn
-r-xr-xr-x. 1 cwebster cwebster  429 Sep  3  2015 start_vsftpd
-r-xr-xr-x. 1 cwebster cwebster  788 Dec 15  2015 update_samba
[cwebster@klink CymSTAR_Linux_Support]$

You did not send the mkisofs command line arguments...

It may be that brasero is trying to create a UDF filesystem and Redhat is shipping extremely outdated software, e.g. mkisofs/cdrecord from May 2004 when Debian decided to attack the cdrtools project and started an unmaintained fork from the state from May 2004. Redhat unfortunatly ships this 12 year old dead fork.

Since then, mkisofs and cdrecord have been massively evolved.

A mkisofs from 2004 did not support to forward correct file permissions to the UDF file system. The original software added this feature in 2007, together with options -udf vs. -UDF as with -r vs. -R.

I recommend you to install recent original cdrtools from either 

https://sourceforge.net/projects/cdrtools/files/alpha/

or from the schilytools bundle at:

http://sourceforge.net/projects/schilytools/files/

Make sure to install cdrecord + cdda2wav suid root or use the capabilities based install method.

Make sure to verify that brasero will really use the original software and not the dead fork from 2004.

The curent version is 3.02a06.

Note that all current cdrtools programs support the option "-version" and include "Joerg Schilling" in the text from the first line of the -version output.

(In reply to Jörg Schilling from comment #3)
> You did not send the mkisofs command line arguments...

I'm not sure what you mean. I listed the entire command line for both mkisofs and cdrecord in my initial post.

> It may be that brasero is trying to create a UDF filesystem and Redhat is
> shipping extremely outdated software, e.g. mkisofs/cdrecord from May 2004
> when Debian decided to attack the cdrtools project and started an
> unmaintained fork from the state from May 2004. Redhat unfortunatly ships
> this 12 year old dead fork.

I don't think this was an issue with either mkisofs (genisoimage) or cdrecord (wodim). The problem only appeared with brasero/brasero-nautilus version 2.30.3-3 that came with the RHEL/CentOS 6.8 point release. When I downgraded to the previous version (2.28.3-6) the problem went away. I did not change mkisofs or cdrecord.

As I indicated in my original post, I was able to successfully create optical discs with correct permissions using mkisofs and cdrecord.

> Since then, mkisofs and cdrecord have been massively evolved.
[snip]

I always wondered why "man mkisofs" brought up the genisoimage manual and "man cdrecord" gave me wodim.

I did some reading about your struggle with these tools... thank you for taking time to comment. I will bear this in mind for future issues.

> Note that all current cdrtools programs support the option "-version" and
> include "Joerg Schilling" in the text from the first line of the -version
> output.

As you predicted:

[cwebster@klink av8b98]$ mkisofs -version
mkisofs 2.01 is not what you see here. This line is only a fake for too clever
GUIs and other frontend applications. In fact, this program is:
genisoimage 1.1.9 (Linux)
[cwebster@klink av8b98]$ 

[cwebster@klink av8b98]$ cdrecord -version
Cdrecord-yelling-line-to-tell-frontends-to-use-it-like-version 2.01.01a03-dvd 
Wodim 1.1.9
Copyright (C) 2006 Cdrkit suite contributors
Based on works from Joerg Schilling, Copyright (C) 1995-2006, J. Schilling
[cwebster@klink av8b98]$ 

Myself and my clients use RHEL and CentOS because they are by-in-large very stable. There are always going to be trade-offs so I will occasionally replace native RH-provided pkgs to overcome issues. This particular issue is being handled for now, though.

Brasero is not a writing program, it is just a frontend.

If you complain about brasero, you should send the command lines used by brasero but these command lines are missing.

BTW: these programs from "cdrkit" still have the aprox. 100 Debian specific bugs that have been introduced by Debian in 2004.

If your Linux distro does not update the software you are using, you may like to check other Linux distros that do upgrade the software on a regular base.

Also note that you may be a victim of the fact that Debian and other OSS hostile Linux distributors modified brasero to prevent it from working correctly with the original cdrtools. 

Did you ever compile a recent brasero by your own and tested it with self compiled original cdrtools?

(In reply to Jörg Schilling from comment #8)
> Brasero is not a writing program, it is just a frontend.
> 
> If you complain about brasero, you should send the command lines used by
> brasero but these command lines are missing.

Until now, I really didn't care what back-end command line arguments were being used. Usually it just works so there's no need to worry about it. Time is money... the less time I have to spend troubleshooting tools, the more time I can devote to my clients. Brasero doesn't advertise the back-end so I had to start it with some debug flags. I was hoping to compare debug logs from both old (working) and new (broken) versions.

The previous (working) version, brasero-2.28.3-6, gave up some pertinent info in the debug log. I ran the following command to start brasero and send debug output to the log.

brasero -g --brasero-media-debug > brasero-2.28.3-6.debug.log 2>&1

brasero-2.28.3-6.debug.log
--------------------------
...
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-cdrecord.so
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin.c:1041: Module encountered an error while registering its capabilities:
"cdrecord" is a symbolic link pointing to another program. Use the target program instead
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:481: Load failure, no GType was returned "cdrecord" is a symbolic link pointing to another program. Use the target program instead
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-growisofs.so
...
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-mkisofs.so
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin.c:1041: Module encountered an error while registering its capabilities:
"mkisofs" is a symbolic link pointing to another program. Use the target program instead
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:481: Load failure, no GType was returned "mkisofs" is a symbolic link pointing to another program. Use the target program instead
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-cdrdao.so
...
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-vob.so
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin.c:1041: Module encountered an error while registering its capabilities:
"mplex" element could not be created
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:481: Load failure, no GType was returned "mplex" element could not be created
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-burn-uri.so
...
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-dvdauthor.so
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin.c:1041: Module encountered an error while registering its capabilities:
"dvdauthor" could not be found in the path
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:481: Load failure, no GType was returned "dvdauthor" could not be found in the path
(brasero:12083): BraseroBurn-DEBUG: At burn-plugin-manager.c:156: Getting list of plugins to be loaded
...
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:186: BraseroGenisoimage got varg:
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      /usr/bin/genisoimage
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -input-charset
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      utf8
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -r
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -J
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -graft-points
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -path-list
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      /tmp/brasero_tmp_YEKJJY
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -exclude-list
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      /tmp/brasero_tmp_UNKJJY
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -V
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      Data disc (23 Jun 16)
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -A
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      Brasero-2.28.3
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -sysid
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      LINUX
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      -o
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:190:      /home/cwebster/Downloads/CymSTAR/ColdStart/InstallDisks/CymSTAR_Linux_Support.brasero-2.28.3-6.20160623.iso
(brasero:12083): BraseroBurn-DEBUG: At burn-process.c:620: BraseroGenisoimage Launching command
--------------------------


The current (broken) version, brasero-2.30.3-3, had a completely different debug output. None of the command line arguments are listed. In fact, I found nothing useful at all in that debug log. I've attached it in case someone wants to look through it. I used the following command to create it.

brasero --brasero-burn-debug --brasero-media-debug > brasero-2.30.3-3.debug.log 2>&1

I also tried several variations of removing and adding flags to mkisofs (genisoimage) to see if I could *make* it fail the way I saw brasero fail. Nothing I did removed the execute permissions from files in the ISO image.

mkisofs -o ISO_Image_name.iso -J -r -V FS_Label Source_Directory/
mkisofs -o ISO_Image_name.iso -J -R -V FS_Label Source_Directory/
mkisofs -o ISO_Image_name.iso -J -V FS_Label Source_Directory/
mkisofs -o ISO_Image_name.iso -V FS_Label Source_Directory/



> BTW: these programs from "cdrkit" still have the aprox. 100 Debian specific
> bugs that have been introduced by Debian in 2004.
> 
> If your Linux distro does not update the software you are using, you may
> like to check other Linux distros that do upgrade the software on a regular
> base.
> 
> Also note that you may be a victim of the fact that Debian and other OSS
> hostile Linux distributors modified brasero to prevent it from working
> correctly with the original cdrtools. 

Surely, you're not suggesting that Red Hat purposely sabotaged this software are you? I could be persuaded that someone made a poor design choice on back-end software but I doubt there was any malicious intent here. Since Fedora feeds Enterprise Linux, I think it was just a matter of "this is what's available in Fedora, so that's what we're going with".

> Did you ever compile a recent brasero by your own and tested it with self
> compiled original cdrtools?

No, haven't done any of that in over a decade. I used to do it all the time a few decades ago, back in my SCO Unix, Slackware, and Red Hat Linux (prior to RHEL) days.

Switching distros is not an option for myself or clients, certainly not just for an accessory like this. The work-around of reverting to the previous version is good enough for now. Long term stability will always trump minor hickups like this.

Thanks for your feedback, though. :-)

Created attachment 1171681 [details]
brasero-2.30.3-3 debug log

Created with this command to look for back-end command-line arguments used.

brasero --brasero-burn-debug --brasero-media-debug > brasero-2.30.3-3.debug.log 2>&1

Version 2.28.3-6 produced a log with explicit reference to genisoimage args but this version does not.

So from the log from the answer from 2016-06-23 15:20 EDT it is obvious that
the problem is caused by using "libisofs" instead of the known to work
"mkisofs".

To "amit yadav":

I see that you added the "needinfo" flag.

Please leave a comment or email me to let me know whether you need additional information from me.

Regards,

Cal Webster

(In reply to Calvin Webster from comment #13)
> To "amit yadav":
> 
> I see that you added the "needinfo" flag.
> 
> Please leave a comment or email me to let me know whether you need
> additional information from me.
> 
> Regards,
> 
> Cal Webster

Calvin,

The needinfo flag was set for Assignee, not for you. I have asked Engineering for their input on this bug.

I see no reason why there might be a need for additional information.

If the software did use the original mkisofs program to create there was no problem.

See also comment #3 and comment #12

Other Linux distros did revert their mistake (removing mkisofs) long ago, but as long as Redhat remains at the dark side of the force, there is little hope for a change.

The answer for many similar bug reports is still:

Use maintained original software if you don't like problems.

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.