This looks related to report 465. :-)

After rebuilding tdelibs with commit 0536f0b, double-clicking on an ISO image results with a kio message that the file does not exist:

An error occurred while loading iso:/home/public/archives/CD-Images/Slackware-current/slackware-current-install-dvd.iso:
The file or folder /home/public/archives/CD-Images/Slackware-current/slackware-current-install-dvd.iso does not exist.

The message makes no sense since I double-clicked on the file. I think we should address the wording of the error message when we resolve the bug. :-)

If I understand correctly, double-clicking, or using an appropriate context menu option (Open With or Actions), should use something called the ISO9660 Image Viewer or ISO9660 View.

The Actions menu item 'ISO9660 View' comes from $PREFIX/share/apps/konqueror/servicemenus/isoservice.desktop:

Exec=kfmclient exec iso:%f

That implies the viewer is a built-in kio slave.

Similarly, the Open With menu item ISO9660 Image Viewer is from /opt/trinity/share/applnk/kio_iso.desktop:

Exec=konqueror iso:%f

That too implies the viewer is a built-in kio slave.

At this point I'm guessing the kio_iso slave is not working?

Hmmm...double-click works fine here (tested on a Kubuntu CD iso).  I noticed you tested with a DVD ISO; do CD ISOs work for you?

Bingo. :-) A CD image works fine. A DVD image does not.

Note: when I viewed a CD image, I saw the following directories:

El Torito Boot
ISO9660
Joliet level 3

The first two directories expanded as expected. The Joliet directory expands to a bunch of jibberish, a bunch of squares where characters should be. A quick look around the web indicates the older libisofs 0.2 that is part of tdelibs does not support Joliet.

The latest libisofs, 1.2.0, does.

So I guess three questions:

* Will tdelibs build with libisofs that is installed on a system before using the older 0.2 that is part of tdelibs? I'm rebuilding now to test that question, but if not, I would think tdelibs should build that way and fall back to the older 0.2 only as a safety net.

* How much debugging to provide DVD support? Possibly DVD support is resolved by using a new version of libisofs?

* Double-clicking opens a new instance of konqueror. How do we force opening in a new tab?

Update: Rebuilding tdelibs with libisofs 1.2.0 preinstalled makes no difference with seeing the Joliet directory or viewing a DVD. Looking at the sources indicates the older version 0.2 provided with tdelibs is hard-coded into the build.

Maybe we only need to replace the 0.2 sources with those from 1.2.0? Or modify the build process to first look for an installed version?

Web site:

http://libburnia-project.org/wiki/Libisofs

1.2.0 sources:

http://files.libburnia-project.org/releases/libisofs-1.2.0.tar.gz

We should see if the slave will build against the system iso library.  At this point there is no good reason to keep the outdated iso sources in TDE.

libisofs is used many places in the TDE code.  To make matters worse, it looks like the current libisofs has a completely different API than the 0.2 release used in TDE.

For the record, KDE4 uses the same outdated 0.2 version in its sources.  The only potential difference is that they patched a failure on ISO images greater than 4GB, which sounds like it may have some bearing on this problem.

Darrell, is your DVD image greater than 4GB?

KDE4 patch for backporting: https://projects.kde.org/projects/extragear/utils/krusader/repository/revisions/e65a76eb64fc3481832807b9b1e1fadf207437f9/diff

Created attachment 701 [details]
Fix ISO parsing when file is > 4GB

If your DVD was greater than 4GB try this patch and see if it fixes the read problem.

Joliet level 3 is a separate issue that is not addressed with this patch.

As far as I can tell here, anything larger than a CDROM is unviewable. I can view everything less than 700MB but nothing larger.

I'll test the patch.

Patch results: same error, that the file or folder does not exist.

If that is true then KDE4 very likely has the same problem.

I just tried the unpatched kioslave on the 1.9GB TDE DVD image and it worked fine.

Are you sure that the ISO you are trying to view is not corrupt?

Comment on attachment 701 [details]
Fix ISO parsing when file is > 4GB

No adverse effects noted; pushed to GIT in hash b4bba7b.

Joliet failure fixed in GIT hash e202ca7.

I rebuilt tdelibs against latest GIT. Joliet extensions level 1 and 3 list without incident. Great!

Still can't read anything greater than 700MB.

I'm sure my images are fine, they mount and burn without problem. Do you have links to the DVD images you tested?

Still can't figure out how to force opening in a tab rather than new konqueror instance.

Here is the ISO I tested:

http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=cdimages/kubuntu/maverick/kubuntu-10.10-trinity-enterprise-i386.iso

I also tried a Slackware DVD from here:
http://ftp.heanet.ie/mirrors/ftp.slackware.com/pub/slackware/slackware-current-iso/slackware-current-26_Jun_2012-DVD.iso

That also worked just fine.  In case it makes a difference, I am testing on an i686 kernel, version 2.6.38.

I'm going to guess that the reason Konqueror can't open the ISO in the current window is that the ISO slave is not registered (via a service/protocol .desktop file) in such a way that would allow that to work.  Unfortunately I also don't know how to register it correctly at this point.

I can view the contents of kubuntu-10.10-trinity-enterprise-i386.iso using kio_iso. I can view movie DVD images of varying sizes, up to 7.7 GB.

The Slackware DVD images I have here I created using a script and mkisofs:

http://humanreadable.nfshost.com/files/make-slack-dvd

I can mount these Slackware ISO images with loopback. I can burn physical disks with the images that work in different computers. Yet I can't view all images with kio_iso.

My first presumption was the script. I tested and experimented for several hours. Eventually I noticed when I included certain directories in the DVD then kio_iso choked.

Including the following directories might cause kio_iso to fail:

./extra
./patches
./pasture
./source

I wrote 'might' because a directory sometimes caused a failure and sometimes not, depending upon which Slackware release tree I used. For example, include the patches directory when creating a 12.2 DVD causes kio_iso to fail but not when including that directory when creating a Current DVD.

The only 'fail-safe" method I found for my script to work with kio_iso is to exclude all four directories regardless of the Slackware release. Of course, if I don't use kio_iso then including those directories for my physical DVDs works just fine.

Here is a link to Slackware source trees (all releases are the same):

http://slackware.mirrors.tds.net/pub/slackware/

The fact that all images mount, burn, and work from a physical disk, and that including certain directories might cause kio_iso to fail, indicates a flaw with the kio_iso logic not reading correctly. I have beat myself pretty good twisting and testing here and I draw that conclusion. Something in the way kio_iso parses information causes it to choke.

The resulting error message ("The file of folder ... does not exist.") needs to be updated because the statement is false. Where ever kio_iso is failing, using the KIO::ERR_DOES_NOT_EXIST function is just kooky. Some other function, or a new error function is needed to describe the failure. Of course, the failure likely is a bug anyway. The user can see that both the file and the directory exist --- how else could the user double-click on the file?

In iso.cpp, the KIO::ERR_DOES_NOT_EXIST function is used several times but not all those instances are accompanied with kdDebug messages, which renders debugging more challenging. I tried to follow the output as best I could.

To resolve why kio_iso chokes we need some additional kdDebug messages and for temporary testing, probably some printf messages.

Here is a stdout/kdDebug output that fails:

==================================================================
kdesktop (Minicli): Command: iso:/home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso
kdesktop (Minicli): Arguments:
kalarm: Daemon::updateRegisteredStatus() -> 3
kdesktop (Minicli): Command: iso:/home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso
kdesktop (Minicli): Arguments:
kdesktop (Minicli): Use terminal ? false
kio (KRun):  new KRun 0x809eda0 iso:/home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso timer=0x809edf8
tdecore (KConfigSkeleton): KConfigSkeleton::writeConfig()
tdecore (KConfigSkeleton): KConfigSkeleton::readConfig()
kio (KRun): 0x809eda0 slotTimeout called
kio (KRun): INIT called
kio (KRun): Testing directory (stating)
kio (KIOJob): stat iso:/home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso
kio (UIServer): UIServer::newJob observerAppId=kdesktop. Giving id=10
kio (KRun):  Job 0x8178798 is about stating iso:/home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso
kio (UIServer): UIServer::stating 10 iso:/home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso
kio_iso: kio_isoProtocol::stat iso:/home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso
kio_iso: kio_isoProtocol::checkNewFile /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso startsec: -1
kio_iso: Need to open a new file
kio_iso: the full path is /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso/
kio_iso: /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso/  trying /home
kio_iso: /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso/  trying /home/public
kio_iso: /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso/  trying /home/public/archives
kio_iso: /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso/  trying /home/public/archives/CD-Images
kio_iso: /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso/  trying /home/public/archives/CD-Images/slackware-13.1
kio_iso: /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso/  trying /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso
kio_iso: kio_isoProtocol::checkNewFile: not found
kio_iso: kio_isoProtocol::stat (stat) on /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso
kio_iso: isdir=false  errno=No such file or directory
kio (KIOJob): error 11 /home/public/archives/CD-Images/slackware-13.1/slackware-13.1-install-dvd.iso
kio (UIServer): UIServer::jobFinished id=10
kio (KRun): 0x809eda0 slotTimeout called
kio (KRun): KRun::~KRun() 0x809eda0
kio (KRun): KRun::~KRun() done 0x809eda0
==================================================================



Here is a stdout/kdDebug output that succeeds:

==================================================================
kdesktop (Minicli): Command: iso:/home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso
kdesktop (Minicli): Arguments:
kdesktop (Minicli): Command: iso:/home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso
kdesktop (Minicli): Arguments:
kdesktop (Minicli): Use terminal ? false
kio (KRun):  new KRun 0x8095fa8 iso:/home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso timer=0x8096000
tdecore (KConfigSkeleton): KConfigSkeleton::writeConfig()
tdecore (KConfigSkeleton): KConfigSkeleton::readConfig()
kio (KRun): 0x8095fa8 slotTimeout called
kio (KRun): INIT called
kio (KRun): Testing directory (stating)
kio (KIOJob): stat iso:/home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso
kio (UIServer): UIServer::newJob observerAppId=kdesktop. Giving id=11
kio (KRun):  Job 0x80f51c8 is about stating iso:/home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso
kio_iso: kio_isoProtocol::stat iso:/home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso
kio_iso: kio_isoProtocol::checkNewFile /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso startsec: -1
kio_iso: Need to open a new file
kio_iso: the full path is /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso/
kio_iso: /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso/  trying /home
kio_iso: /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso/  trying /home/public
kio_iso: /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso/  trying /home/public/archives
kio_iso: /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso/  trying /home/public/archives/CD-Images
kio_iso: /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso/  trying /home/public/archives/CD-Images/slackware-current
kio_iso: /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso/  trying /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso
kio_iso: kio_isoProtocol::checkNewFile: not found
kio_iso: kio_isoProtocol::stat (stat) on /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso
kio_iso: isdir=false  errno=No such file or directory
kio (UIServer): UIServer::stating 11 iso:/home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso
kio (KIOJob): error 11 /home/public/archives/CD-Images/slackware-current/slackware64-current-install-dvd.iso
kio (UIServer): UIServer::jobFinished id=11
artskde: [void KDE::POFHelper::connectAmanPlay()]
kio (KRun): 0x8095fa8 slotTimeout called
==================================================================

The difference seems to be at the end with UIServer.

I hope this helps.

Can you provide a link to a DVD image that you know will fail so that I can debug it?  I don't want to get into building CD images here just to fix this potential bug report (I label it potential because I suspect something is probably violating the ISO standard somewhere, even if you can access most or all of the data on a physical disk burned from the faulty ISO).

Regarding test images, I have none online. As I am restricted with bandwidth caps by the ISP, I need to be careful with sizes. I'll try to create a small DVD that still fails.

In the mean time, here is some more data.

I noticed that kio_iso would not display the contents of a commercial (Asus motherboard) DVD image on my hard drive. Of course, there are no problems with mount -o loop.

Curious, I created a new image using k3b and the same physical disk. This is a data DVD, not a movie DVD or audio CD. Thus no special disk structures.

kio_iso would view the new image on my hard drive, but some files had mimetypes of Unknown. Mounting the new image with mount -o loop showed the same incorrect mimetypes.

Creating a new image using dd if=/dev/dvd of=asus.iso resulted in all files in that image showing correct mimetypes but kio_iso failing to view the contents.

This would tend to confirm a flaw in the kio_iso logic, but add a probable bug with k3b. Possibly, because k3b is basically a wrapper to various command line utilities, this bug could be a result of whatever tool k3b uses to copy and create the disk image.

Next I mounted the DVD and ran a simple mkisofs command to create another image:

mkisofs -o asus2.iso -rock -joliet -iso-level 3 -v .

That effort resulted in kio_iso failing to view the image. Mount -o loop worked fine and the mimetypes were correct.

I did not find a copy online of the Asus DVD.

I seem unable to find any combination that creates a smaller DVD that fails. When I exclude other directories and include the original (perceived) problematic directories, kio_iso views the image.

I'm starting to lean toward the idea there is a size thresh hold causing this. Either in the kio_iso sources or in the ISO standard. As I waste my day tinkering with different combinations of directories, I'm noticing that at just over 2.0 GB kio_iso chokes.

The Asus disk is 2.1 GB. Can't view.

When I create Slackware DVDs, what directories I exclude now seems irrelevant, as long as I don't exceed ~ 2.0 GB.

kio_iso fails:

Asus disk: 2,205,384,704 bytes
Test DVD: 2,150,057,984 bytes

kio_iso succeeds:

Test DVD: 2,119,036.928 bytes
kubuntu-10.10-trinity-enterprise-i386.iso: 1,965,139,968 bytes

If you still have the disk image, what is the exact size of the slackware-current-26_Jun_2012-DVD.iso you tested?

I'll take a wild _ss non-scientific guess the cutoff is exactly 2GB: 2,147,483,648 bytes.

Looks like 2 GB is the magic choke point:

Test DVD: 2,147,708,928 bytes -> kio_iso fails

2 GB  ==  2,147,483,648 bytes

Test DVD: 2,147,342,336 bytes -> kio_iso succeeds

Was this tested with the b4bba7b patch?  If so, I wonder if the original KDE4 patch was somewhat flawed and I think I know where the problem is.

Yes, with the patch --- tdelibs is up to date.

Created attachment 702 [details]
Fix ISO parsing when file is > 2GB

Try this patch.

As soon as I discovered the 2 GB trip point I started looking for what C++ requires for integer declaration. When I saw the patch for long -> long long I figured this was a done deal.

Yet kio_iso still refuses to play with > 2 GB. :-(

Odd.  There must be more instances of "int" and/or "long" that need conversion to "long long".

(In reply to comment #29)
> As soon as I discovered the 2 GB trip point I started looking for what C++
> requires for integer declaration. When I saw the patch for long -> long long I
> figured this was a done deal.
> 
> Yet kio_iso still refuses to play with > 2 GB. :-(

Are you sure the patch actually applied and the new code is installed?  Note that you probably need to log out and log in before it would take effect.

I ask because I just tried a 3.3GB DVD image on my 32-bit test system (with the patch applied) and it worked fine.

Also, are you using a 32-bit or 64-bit kernel?

Comment on attachment 702 [details]
Fix ISO parsing when file is > 2GB

This patch will still be needed even if another problem is found; pushed in GIT hash dca4c67.

The build log indicates the patch was applied before building. I always exit and restart the session with package changes. :-)

I resynced the tdelibs tree. I'll rebuild again.

I'm using a 32-bit system. The kernel is 32-bit with PAE enabled.

The error message that the "file or folder...does not exist" to me implies a parsing problem.

Are there any system dependencies that you might have installed that I do not?

(In reply to comment #33)
> I'm using a 32-bit system. The kernel is 32-bit with PAE enabled.
> 
> The error message that the "file or folder...does not exist" to me implies a
> parsing problem.

As you pointed out earlier, there are a number of places that the kioslave can exit with that (incorrect) status.  It might help to know exactly which exit point is being triggered.

> Are there any system dependencies that you might have installed that I do not?

Not that I know of--the kioslave is very lean on external system library dependencies.

I added fprintf messages at each place where KIO::ERR_DOES_NOT_EXIST is called in iso.cpp. Here is where the "does not exist" error message is generated in my usage:

void kio_isoProtocol::stat( const KURL & url )
{
    TQString path;
    UDSEntry entry;

    kdDebug() << "kio_isoProtocol::stat " << url.url() << endl;
    if ( !checkNewFile( url.path(), path, url.hasRef() ? url.htmlRef().toInt() : -1 ) )
    {
        // We may be looking at a real directory - this happens
        // when pressing up after being in the root of an archive
        TQCString _path( TQFile::encodeName(url.path()));
        kdDebug()  << "kio_isoProtocol::stat (stat) on " << _path << endl;
        struct stat buff;
        if ( ::stat( _path.data(), &buff ) == -1 || !S_ISDIR( buff.st_mode ) ) {
            kdDebug() << "isdir=" << S_ISDIR( buff.st_mode ) << "  errno=" << strerror(errno) << endl;
            fprintf(stderr, "Test message 2.\n");
            error( KIO::ERR_DOES_NOT_EXIST, url.path() );
            return;
        }

In the unmodified code that would be at iso.cpp:316, but I left the fprintf message as-is so you could see how I tracked this.

I don't understand what that function is doing, but I am not double-clicking on an actual directory. I am double-clicking on an *.iso file.

I hope that helps.

To debug this further I really need access to a known-failing (Slackware?) ISO file.  Is there anyone you know who might be able to host a known-failing ISO so that I can obtain a copy of it?

Try this one:

http://slackware.mirrors.tds.net/pub/slackware/slackware-13.1-iso/slackware-13.1-install-dvd.iso

Uploading an image I made will require several hours. Even after getting that far I don't budget the money for such upload or download bandwidth at my web site.

Quite understandable.  So the linked ISO image fails when you test it?  I am downloading it now.

slackware-13.1-install-dvd.iso opens just fine on my test system.  Right now I'm leaning toward something being slightly wrong/weird on your system rather than another bug in the ISO kioslave.

I appreciate your patience. I too am leaning toward something amiss on my system.

My first guess is the way my script builds an ISO image. The script mostly is a copy of a popular script used by many Slackers. Of course, probably nobody but me is trying to get kio_iso working. Thus, nobody is likely to ever notice anything amiss with the script in that respect.

Hopefully you have not deleted the ISO image you downloaded. If not then would you run my script to create a new image?

* Extract the contents of the ISO image.
* Tweak the script directory references for your system:

  ROOT_PATH="/home/public/slackware${TYPE}/$VERSION"
  ISO_NAME="slackware${TYPE}-$VERSION-install-dvd.iso"
  DVD_PATH="/home/public/archives/CD-Images"

* Run the script to build a new ISO image.
* Test kio_iso.

Oops. I provided a link to the script several comments ago. Here is the link:

http://humanreadable.nfshost.com/files/make-slack-dvd

The provided script bombs out when I try to run it on my Ubuntu systems.

Sorry I can't help much more with this!

Yes, my mistake! The original script sources some localized script containers. I modified the script to use those snippets directly rather than sourcing:

http://humanreadable.nfshost.com/trinity/patches/make-slack-dvd

You still need to modify the following for your system:

ROOT_PATH="/home/public/slackware${TYPE}/$VERSION"
ISO_NAME="slackware${TYPE}-$VERSION-install-dvd.iso"
DVD_PATH="/home/public/archives/CD-Images"

Your script still doesn't work here:

./make-slack-dvd
No parameters passed: using the currently installed release.
cat: /etc/slackware-version: No such file or directory
-e The directory /home/public/archives/CD-Images/Slackware- does not exist!
./make-slack-dvd: 16: ./make-slack-dvd: Bad substitution

Definitely a Slackware-only script. :-)

I uploaded a modified version. At lines 167 and 168, the following variables need to be modified for your system:

ROOT_PATH="/home/public/slackware${TYPE}/$VERSION"
DVD_PATH="/home/public/archives/CD-Images"

ROOT_PATH is where you copied the ISO image files. The variables TYPE and VERSION are not needed for your special setup, so the entire path should just point to whereever you unpacked the image files.

DVD_PATH is where you want to create the new ISO image, such as /tmp/, var/tmp, $HOME, or whatever is appropriate for your test setup. Of course, you need sufficient space. :-)

For example, the modified lines might look like this:

ROOT_PATH="/tmp/slackware-13.1-install-dvd"
DVD_PATH="/tmp"

or

ROOT_PATH="$HOME/slackware-13.1-install-dvd"
DVD_PATH="$HOME"

Note: I tried to burn an ISO image using K3B. I received the following dialog:

"The image you selected is not a valid ISO9660 image."

The string is from k3bisoimagewritingdialog.cpp:238.

I do not receive this dialog when doing the same thing in 3.5.10.

This new information is inconclusive, but probably does help one way or another.

I believe this bug report is related to 1111, "K3B: Fails to recognize certain ISO images." Although the two bug reports might not be related, the common failures seem more than a coincidence. I suspect something awry with the builtin libisofs.

k3b also is packaged with libisofs 0.2. As the libisofs directories in tdelibs and k3b are more or less the same, seems that something else common to building libisofs 0.2 might be the cause.

That the k3b failure in bug report 1111 does not occur in 3.5.10 indicates a regression somewhere in Trinity.

The problem is unlikely to be mkisofs because the same ISO images are readable in k3b 3.5.10.

I'm certain this bug report is related to bug report 1111 and the problem lies within the common libisofs of both kio-iso and k3b.

The problem is limited to 32-bit systems. Both kio-iso and k3b recognize DVD ISO images without fail in a 64-bit system but not within a 32-bit system.

I'm guessing the problem is an int/long versus long long variable type declaration or something similar.

How big should the file be? I tried to make ISO 3.2 GiB large and have not noticed a problem in 3.5.13-sru.

Did you test on a 32-bit or 64-bit system?

According to the previous discussion, the threshhold is 2 GB. Yet as I mentioned recently, I can duplicate this bug only on 32-bit systems. The bug disappears on 64-bit systems.

I was aware of your knowledge and tested on a 32bit system. I had file 3.2 GiB and I have not noticed any problem even in kio-iso or in k3b.

3.5.13.1 on 32bit Debian Squeeze

(In reply to comment #33)
> I'm using a 32-bit system. The kernel is 32-bit with PAE enabled.

Can you try with a kernel which does not have PAE enabled, just in case something is amiss there?

Thanks!

Tim

I rebooted with a non PAE kernel with the same result. I rebuilt k3b on that non PAE kernel with the same result. I suspect those tests are inconclusive as all of TDE probably should be rebuilt on the same non PAE kernel before deciding whether the problem is the kernel.

For sure there is a difference between my 32-bit and 64-bit systems.

Note: I tested with 3.5.13.1 on 32bit kernel with PAE. And problem I did not notice.

(In reply to comment #54)
> Note: I tested with 3.5.13.1 on 32bit kernel with PAE. And problem I did not
> notice.

Darrell, I hate to say this but I think something subtle is broken in your distribution; i.e. one of your system libraries that libisofs depends on must not have proper support for 64 bit variables/files/etc.  As Bug 1111 is essentially the same issue issue and was also already patched in the the same way, I am going to combine the two reports and mark this one RESOLVED NOTOURPROBLEM.

I understand others not wanting to help, I understand accountants closing open items to count their beans, I understand changing the bug report platform to i386/Slackware, but I don't understand closing the bug report.

OK, here's why: this bug report has the wrong name and wrong scope.  It should cover all libisofs failure on Slackware (including Bug 1111), but doesn't.  I don't want two bugs open to track one issue, so if you would rather close both of these reports and write a new one to track the single Slackware 32-bit libisofs issue that would be fine with me.

It's not so much bean counting as it is making sure that the fix in one module is propagated to the other module, and also not confusing anyone else who may run across a similar issue with a different cause in the future. ;-)

The patch pushed in commit 5feb80c8 2012-09-29 seems to have resolved the problem. Refer to bug report 1111 for details.

*** This bug has been marked as a duplicate of bug 1111 ***