Re: Joliet extensions and files with no filename extension

[Mike Jones <mrjones69 gmail com>]

Well, it turns out that on RHEL7, the mkisofs is a symbolic-link to the 
/etc/alternatives stuff and it is really pointing to genisoimage.
So the real mkisofs is not there at all.
For my specific purposes, the genisoimage seems to work correctly (or at 
least as I expect it to).

In brasero, there are precious few settings you can mess with.
Under the Edit->Plugins menu, you can see what it found, but cannot 
change much.
It realizes that mkisofs is a symbolic link and has it unchecked and 
then the genisoimage is checked.
These are all disabled/read-only and just FYI. Have not found a way to 
unlock that so it can be messed with.

I couldn't find any xorriso package in the RHEL repos, so I downloaded 
the source code and compiled it.
ldd on xorriso does not show it using anyone's flavor of libisofs.so.
Looking at the makefile, it looks like the xorriso libisofs .o files are 
linked directly into the executable, so that makes sense.

I didn't think to dig deeper on the brasero "plugin" libraries. I guess 
they're just thin wrappers around other stuff.
An ldd on the brasero-libisofs.so shows that it links 
/lib64/libisofs.so.6 which I see is from your project.
Now I'm in sync with you. :)

The libisofs package on RHEL7 is version 1.2.8 built in January 2014.

Let's see if I am savvy enough with Google Drive. Never used it before.
Please try this link to download "brasero.iso".

https://drive.google.com/open?id=0B-hhKrbg0d77TmlSMlNVTkI4aHM

There is a single, empty file called "no_ext" in the image.

I am using the IsoBuster program to analyze these discs and images.
One cosmetic(?) oddity is that the Joliet extension's name looks truncated.
The volume name is just the date "21 Jul 16", but on the Joliet 
extension it shows as just "21 Ju".

I really appreciate the help and education, gentlemen.

Thanks!

- Mike


On 7/21/2016 7:27 AM, Thomas Schmitt wrote:
> Hi,
>
> Joerg Schilling wrote:
> > be careful not to use the "genisoimage" program
> Well, as a Debian user, i have it installed. No dot to see at the end
> of Joliet names.
>
>
> Mike Jones wrote:
> > I tried the xorriso, version 1.4.4 [...]
> > It too works as expected with no dot added.
> I would have wondered if the dot appeared.
>
> Can you produce by Brasero a small ISO image which demonstrates the problem
> and put it somewhere for me to download ?
> I will then try to find out why a mount facility comes to the idea to
> show a dot.
>
>
> > (and it reports using its own libisofs
> > version 1.4.4).
> If you got xorriso from a RHEL package, then it is probably the dynamically
> linked one from libisoburn. If so, then its reported libisofs version is
> the one from the installed libisofs.so, which Brasero's plugin is supposed
> to use too.
> You can check by
>
>    ldd $(which xorriso) | grep libisofs
>
> which with my Debian packaged xorriso says
>
>    libisofs.so.6 => /usr/lib/x86_64-linux-gnu/libisofs.so.6 (0x00007fbc7c9ef000)
>
> Hopping along the link chain i end at libisofs.so.6.68.0 (which is
> libisofs-1.3.2, as delivered by Debian 8).
>
> If it reports "libisofs", Brasero should show linking with libisofs, too:
>
>    ldd $(which brasero) | grep libisofs
>
> or
>
>    ldd /usr/lib64/brasero3/plugins/libbrasero-libisofs.so | grep libisofs
>
>
> > Starting to look like the brasero version of "libisofs" is the odd-library
> > out?
> I am very sure that Brasero has no own copy of libisofs but rather
> uses an installed libisofs.so. Its plugin module  libbrasero-libisofs.so
> might be buggy or might just have tripped over a libisofs bug which is
> not easy to trigger ... or something in our assumptions is wrong.
>
> We should re-assess the overall problem. See my wish to inspect an ISO
> made by Brasero.
>
>
> > there's some overloading of the "libisofs" name.
> > Looks like several projects all have their own version/flavor of it.
> libisofs.so.6 exists since 2006, versions range from 0.2.3 to 1.4.4.
> There was a predecessor (forgot its .so number) and there is a read-only
> "libisofs" announced at
>    http://libcdrom.sourceforge.net/libisofs.html
> which is unrelated to libisofs.so.6.
>
> In contemproray distros, "libisofs" is the one which i maintain.
> Its age varies widely, though.
>
>
> Have a nice day :)
>
> Thomas