I have a backup script that I run that seems to work fine except about 1-2 weeks ago Dolphin stopped being able to "open archive as folder". The script has not changed and Ark and File-roller open the archive fine but not Dolphin. Dolphin gives the following error:

Could not open the file, probably due to an unsupported file format.

During this period I did up to openSUSE 12.2rc2

note: using the service menu compress -> compress to tar, creates archives that Dolphin can "open archive as folder".

the backup script is:

nice tar -cf $NAME_DAT \
--exclude=*~ \
--exclude=*adblock* \
--exclude=*.zip \
<snip>
~

I'm guessing this does not work under a new user either?
On my system Dolphin starts Ark to handle this - while Konqueror properly invokes the tar:/ KIO slave to open the tarball.

diff user same error and again opens fine in Ark

think do to timing it's something in openSUSE 12.2rc2, but as Arks opens it fine ...................

Does Konqueror handle it properly?
Alternately, try entering "tar:/full/path/to/tarball.tar/ in the location bar in Dolphin and see if that works.

same error with Konq and with tar:/ kio

This isn't of much help, but i tried a simple

Code: Select all

tar -cvf lato.tar.gz LatoOFL/

Code: Select all

rpm -q --info tar
Name        : tar
Version     : 1.26
Release     : 11.1.2
Architecture: x86_64
...
Source RPM  : tar-1.26-11.1.2.src.rpm
...
Distribution: openSUSE 12.2

Works fine here

Can you please run "file --mime-type" against one of these tar archives? Hopefully it returns "application/x-tar".
Also, does compressing your files (assuming they are uncompressed) have any impact?

> file --mime-type 'test -open-archive-as-folder.tar'
test -open-archive-as-folder.tar: application/x-tar

normally they are compressed bzip2, and neither the compressed or uncompressed tar file works

The mimetypes of the compressed (and uncompressed) archives?

mime types:

tar file = application/x-tar
bzip2 file = application/x-bizp

Would it be possible for you to post one of the tar archives generated by your system somewhere so I can test against it?
I tried with tar archives generated locally here - and they are fine.

(The portion of the stack involved resides in kdecore here - which is fairly concerning).

it's pretty large file (6mb)and it's my personal info backup so I'd prefer not to

need to point out (as mentioned in op) using the service menus to tar and then bzip the resultant archive works fine but my script is now creating archives that Dolphin and Konq can not open as folders, the older archive created with same scripts still open as folders fine

late today I'll try and create a small'ish archive that's problematic

here's the complete backup script for my Opera files that also no longer works

Code: Select all

#!/bin/bash
DATUM=`date +%Y-%m-%d--%H-%M`
echo "$DATUM"
# Directory to save backup

# NAME_DAT="/windows/e/OperaBkup.$DATUM.tar"
NAME_DAT="BkupOpera.$DATUM.tar"

echo $NAME_DAT

# -- '--no-recursion' option to work:
# must go before 'cvfx' command and must use * ie ~/*
# directories must end with a '/'?
# lines much end with '\' for continuation
# remember - dir. names are relative
cd ~/.opera
nice tar -cf $NAME_DAT \
--exclude=*adr.bak  \
--exclude=BkupOpera* \
--exclude=browser.js \
--exclude=cache4  \
--exclude=cacheop  \
--exclude=cache*  \
--exclude=cdownload.dat*  \
--exclude=dictionaries \
--exclude=fontcache.txt \
--exclude=gconf*  \
--exclude=global.dat \
--exclude=icons \
--exclude=images  \
--exclude=images-bkup  \
--exclude=img  \
--exclude=images \
--exclude=lock \
--exclude=mail/lexicon  \
--exclude=mail/recovery.log  \
--exclude=mail/newsfeeds/feed_*  \
--exclude=mplay* \
--exclude=opcache \
--exclude=opcacrt6.dat \
--exclude=oprqtssnd \
--exclude=opcert6.dat \
--exclude=opicacrt6.dat  \
--exclude=oprand.dat \
--exclude=opssl6.dat \
--exclude=orbit*  \
--exclude=override.ini \
--exclude=skin  \
--exclude=thumbnails \
--exclude=temporary_downloads \
--exclude=*tmp*.xpi  \
--exclude=*.tmp  \
--exclude=vlink4.dat  \
--exclude=vps  \
~/.opera

# Zipping files
bzip2 $NAME_DAT
mv $NAME_DAT.bz2 /MyBackUp/Backup-Opera

Hmm... interesting. It could be the encoding of filenames. Could you compare the file listings of a working and non-working archive?

here's a pic listing of the names the names, the first ones work but not the last 2


the names are all generated in the script (I have not changed this part)

Code: Select all

DATUM=`date +%Y-%m-%d--%H-%M`
NAME_DAT="BkupOpera.$DATUM.tar"
<snip>
bzip2 $NAME_DAT
mv $NAME_DAT.bz2 /MyBackUp/Backup-Opera

the file sizes are either 5mb or 27mb or so, this is not different between the ones that work and the ones that don't but wonder if something is different in the tar lib (openSUSE 12.1 and 12.2rc2) when it comes to generating large archives?

I un-bzip2'ed one of the files and could not open the uncompressed tar file as a folder. But deleting files from the tar so that the tar was now 2mb (or so) instead of 27mb and Dolphin could open the tar file as a folder.

So either size somehow matters, possible to do with up'ing distro to 12.2rc2, or deleting contents from the tar affected something in the structure of the file