Iso's don't mount correctly through 'archive mounter'

[Baggers]

Binary package hint: nautilus

Archive mounter is working correctly for Zips, Tars, etc however when I mount an ISO it appears to work but all the filenames in the mounted archive have ';1' appended to the end.

e.g. 'install.exe' becomes 'install.exe;1'

Also the folders contained in the archive have no contents.
I have successfully mounted the same ISO with Gmount-iso and all is well so I assume it to be an issue with the 'Archive Mounter'

I am a total newbie at the bug reporting malarkey so I expect I have broken all kinds of bug posting etiquette, please let me know if this is so.
Cheers

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/bin/nautilus
NonfreeKernelModules: nvidia
Package: nautilus 1:2.24.1-0ubuntu1
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
Uname: Linux 2.6.27-7-generic i686

[Scott Ritchie (scottritchie)]

Confirmed. This is rather annoying, especially since GMount-ISO seems to do it properly.

[tgpraveen (tgpraveen89)]

affects me too.
this really makes archive-mounter useless for me. this bug should be given a higher level and action must be taken to rectify it before the next release.

[Gavin Hamill (gdh)]

+1 - Archive Mounter is a liability to the user experience right now. It would be better to force people to 'mount -o loop ... bla bla' .. or to install 'cdemu'

[puntarenas (puntarenas)]

I can confirm this bug and it drove me nuts when I tried copying files from sysresccd.iso over to my usbstick. I ended up having boot errors and it took me some time to find this bug to be responsible.

I also cannot understand why this is low priority, but as long as gvfs is not able to mount ISOs in a usable fashion, it should maybe not provide this functionality via context menu at all. People tend to think functions are sane when provided under Gnome and so did I.

[Andaril (andaril)]

this thing have place only on some tips of iso, if you make iso with Brasero this bug should not appear, more important is the direction where iso is mounted, no program can found it.

[Tyson Williams (bender2k14)]

I am not sure if one of these bug reports should be a duplicate, but here is another bug report for a different package that is also having this issue:
https://bugs.launchpad.net/gmount-iso/+bug/303448

[Charles P. Collins IV (thought-engineer)]

This is a terrible error. I experience this with every iso.

[Sebastien Bacher (seb128)]

the issue is a libarchive one, in any case not a jaunty blocker it doesn't happen on all iso and the mounter is only a context menu option

[quit (mdikdan)]

The problem is still persistent in version 9.04.

[Derek White (d-man97)]

I confirm as well on 9.04, happens with all iso's I have created with DeVeDe and various other iso's.

Right-click on iso and select 'Open with "Archive Mounter"'.

From OP: "Also the folders contained in the archive have no contents." - no idea what this is, folders are fine for me, not even the ;1 on them, the ;1 is only on files, folders are fine and can be opened fine with their contents listed (albeit with the ;1).

[Derek White (d-man97)]

Gnome Bug 562673 – gvfsd-archive mounts files with uppercase filename
Resolved by adding Joliet extension support to libarchive.

...

Why is that bug linked to this one?
Is the missing Joliet extension support also causing the addition of ;1 to filenames?
If not, can we remove the external bug watch?
If it is in fact correct, in which version of libarchive can we expect to see the fix? (Up-to-date Ubuntu 9.04 is using the libarchive1 package, version 2.4.17-2.)

[Bordiga Giacomo (gbordiga)]

The support for Joliet extension has been added to Libarchive 2.7.0 . It will propably resolve the problems reported.

[Gavin Hamill (gdh)]

Yep - current Karmic alpha 5 mounts ISOs properly and does not show ;1 at the end of each filename

[Sergey "Shnatsel" Davidoff (shnatsel)]

Everything works fine in Karmic RC. I'm marking the bug as fixed.

[Francis De Brabandere (francisdb)]

I'm still having this issue with karmic rc
libarchive is at version 2.6.2-1 here

[Sergey "Shnatsel" Davidoff (shnatsel)]

Hmm... Can you upload a sample image which is mounted incorrectly?

[Francis De Brabandere (francisdb)]

Sorry, I was a bit too fast, this is indeed fixed. Thanks

[manzur (sl-solaris)]

I am having a similar problem but it is not about the ;1 in the end of a file name, it is that some ISO files can not be mounted properly, They seem to be mounted but when I double click to open them, nothing is inside...

And it is not a problem with the ISO file, because after I burn it I can play what ever is inside

[Sergey "Shnatsel" Davidoff (shnatsel)]

Manzur, is the ISO file opened with File Roller? Can you attach a
sample ISO which isn't mounted properly?

[manzur (sl-solaris)]

It is a big one: http://www.mininova.org/tor/2728372
When I was going to open it with FILE MOUNTER after mounted it... it was empty but after burn it everything was Ok

[Sergey "Shnatsel" Davidoff (shnatsel)]

Thanks, I'll try to download the image and investigate this. Does file
roller open it?

[manzur (sl-solaris)]

check the screen shot.. I tried to open it with file roller to see what happened and there you go, at the left side you see the ISO file and on desktop you can see the file mounted

[manzur (sl-solaris)]

when I open it there is nothing inside

[Sergey "Shnatsel" Davidoff (shnatsel)]

Strange... I'd say that the ISO is using Joilet extension if it would not be Karmic... The program clearly drops to plain ISO9660 file table, but why? I think it's better to start a new bug and follow it upstream. Your problem is not related to this bug.

[manzur (sl-solaris)]

I have made a report of this bug... you can follow it in here: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/462028

[manzur (sl-solaris)]

I have set the binary package hint: gvfs - But I am not sure about it

[chyan (cnchyan)]

In karmic,it can't mount a iso file with chinese filenames correctly.

[John Baptist (jepst79)]

This still happens to me for some, not all, ISOs under Lucid. Both Archive Mounter and Archive Manager present extraneous semicolon-ones. Mounting the ISO with the mount command works well. Has anyone else encountered problems?

[Ev][L (klikevil)]

unfixed in Lucid LOL

[Trinexx (trinexx)]

This STILL hasn't been fixed?

[Charles P. Collins IV (thought-engineer)]

Confirmed. Still broken.

Someone needs to attach a small iso to reproduce this error.

[John Baptist (jepst79)]

Unfortunately, all the broken ISO images that I have that suffer this problem are fairly large; too large for an attachment.

I'd like to discuss the particular problems that I'm having and make sure we're all on the same page. I also have a theory what the problem is. Let's say I have an image f.iso. Opening the image in Gnome Archive Manager (file-roller) or mounting it with gvfs (Gnome Archive Mounter) will show "broken" filenames with the ";1" suffix (which is actually a version number, part of the Rock Ridge CD filesystem extensions). However, if I mount the image normally, with the mount command, the file system is shown correctly. Please verify that this so. For example, if I do this:

mkdir f
sudo mount -o loop f.iso f
ls f

...I will see the correct filenames, without the Rock Ridge version number. So whatever the problem is, it is a discrepancy between the CD filesystem as implemented in the kernel versus as implemented in (userspace) gvfs. Assuming that we all agree about this, then we have determined that the problem is in the backend shared by gvfs and file-roller.

Now, let's do another test. Let's use the isoinfo command to see what it thinks about the given image. Try this:

isoinfo -d -i f.iso

On images that suffer this problem, isoinfo always tell me "NO Rock Ridge present" even though the typical ";1" suffix appears, indicating RR extensions. So now it seems like the image was made with RR extensions, but either the userspace tools aren't detecting it, or the presence of RR isn't correctly marked in the image. Can you please verify that the above command reports no RR extensions for all ISO images that suffer this problem?

[Andreas Henriksson (andreas-fatal)]

Hello John Baptist!

Thanks for injecting some positive energy into this bug report. The previous comments has been really demotivating for me.
I'd like to help clear up some confusion, which will hopefully help you out in your quest to find the problem ...

* gvfs (and thus nautilus) uses libarchive, "mount" uses kernel built-in iso filesystem support, file-roller uses genisoimage (e.g. isoinfo). Completely separate implementations. Any problems they share or not are purely by chance. If you want a command-line frontend to libarchive for testing like you're doing with isoinfo for genisoimage, install bsdtar and look at the libarchive specific flags in the bsdtar manpage.

* You're right the ;1 is a version appended to the filename in the image. Rock Ridge is not that common nowadays though. The "Rock Ridge version numbering scheme", if you can call it that, is also used in Joliet Extension (which most isos have nowadays for long filenames which also works on MS Windows).

* Unfortunately sometimes standard documents are a bit vague which results in different iso creating programs doing things differently, which means iso readers have to implement all cases. Upstream libarchive has a test-suite which also tests iso files and all (current) tests ofcourse passes. This means people who have problems need to report which program they used to generate the iso and provide a testcase so the testsuite can be expanded and libarchive support more ways of writing isos. Comments like "This STILL doesn't work?" are completely useless, because it works FOR ALL KNOWN testcases. Unless you (the bug reporter) know which program generated the iso you're having problems with and are able to provide a testcase, noone will be able to help out.

* Please make sure you're testing with the latest libarchive version installed, currently 2.8.4-1 (available in maverick atleast).

// Andreas Henriksson, debian maintainer of libarchive.

[John Baptist (jepst79)]

Andreas,

Thank you for your informative response. I, too, am feeling more optimistic about this bug.

I noticed that isoinfo reports that the problematic images were created with Nero Burning ROM, so I decided to test that tool (version 6.6.0.12; old, but it's what I have). Using the default settings of that program (running under Wine) I was able to produce the enclosed image, which is displayed with incorrect Joliet/RR suffix in both gvfs and file-roller. It's not quite the same problem as I was having with my other images, where filenames were incorrectly rendered in all caps and in some cases truncated, but it is still relevant to this bug. Note that in the enclosed image, directory names are rendered correctly; only filenames have the suffix. I tested this with on stock, up-to-date Ubuntu Lucid; sorry, I didn't have a chance to test it with the very latest.

I have not experimented with Nero Burning ROM extensively to see if different combinations of options produce different results.

I hope this bug will help you diagnose the problem. Let me know if there's any other information I can provide.

[John Baptist (jepst79)]

As a curiosity not directly related to this bug, I've also enclosed another problematic ISO image. This image was made using mkisofs and is displayed correctly by gvfs but incorrectly (with suffixes) in file-roller. The command I used was:

mkisofs -o f.iso -no-rr dir

This is especally odd, since file-roller uses genisofs as its backend, so it seems that we have a case where genisofs can't read files that it itself produces. This is a testament to your claim of the ambiguity of standards documents and the difficulty of implementing them in a way that provides as much compatibility as possible.

[Scott Ritchie (scottritchie)]

Reopening due to above comments.

[Andreas Henriksson (andreas-fatal)]

$ bsdtar -tvf example.iso
drwx------ 3 0 0 2048 jul 27 03:58 .
drwx------ 2 0 0 2048 jul 27 03:36 Documents
-r-------- 1 0 0 179 apr 30 12:32 Documents/examples.desktop
$ bsdtar -tvf ok-in-gvfs-but-bad-in-file-roller-2.iso
drwx------ 2 0 0 2048 jul 27 03:36 .
-r-------- 1 0 0 179 apr 30 12:32 EXAMPLES.DES

Anyone care to explain what's wrong and why this got reopened?

[John Baptist (jepst79)]

Andreas, Scott:

It's true, this bug seems to be fixed in up-to-date Maverick. (But still broken on Lucid.) My other problematic ISOs also work in Maverick. Can the other complainants confirm or deny that the problem is solved?

[John Baptist (jepst79)]

Andreas:

That's for taking care of this and being a supportive bug-fixer.

[Scott Ritchie (scottritchie)]

All right, if it's fixed in Maverick with the remaining cases then it's fixed. Thanks for clarifying.

[Mihai Capotă (mihaic)]

I have the problem in Ubuntu 10.04.

I just created an ISO file with Brasero and mounted it with Nautilus and I see the ;1 appended to file names. Mounting with mount works fine.

[Mihai Capotă (mihaic)]

The same ISO file mounts fine with Nautilus in Ubuntu 10.10.