The only way I seem to be able to mount a tape in this application is to have to format it first. Thus I am unable to restore any backups with it. This is even after I have already re-formatted a tape with it. My hardware: Tyan Thunder K8W S2885 motherboard. Adaptec AHA 2940 SCSI HBA. HP Surestor CC1537A DDS3 DAT tape unit, attached to /dev/st0. Reproducible: Always Steps to Reproduce: 1. Fire up kdat. 2. Try any technique to mount a tape using kdat. 3. A "Sorry Kdat" dialog appears advising me to check my settings. 4. Re-check the steeings, they are fine. 5. Format the tape (24GB as DDS3). (The tape drive responds.) 6. Successfully mount the tape. (The tape drive responds.) Expected Results: The tape should have been mounted at step 2. Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11- gentoo-r7 x86_64) ================================================================= System uname: 2.6.11-gentoo-r7 x86_64 AMD Opteron(tm) Processor 250 Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 15 2005, 23:35:44)] distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6 sys-devel/automake: 1.9.5, 1.8.5-r3, 1.5, 1.7.9-r1, 1.6.3, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-march=opteron -O0 -pipe -g" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config / var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=opteron -O0 -pipe -g" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distcc distlocks nostrip sandbox strict" GENTOO_MIRRORS="http://gentoo.mirror.sdv.fr http://ftp.easynet.nl/mirror/gentoo/ http:// www.gigaload.org/gentoo.org/ http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/ distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/dev/shm/portage/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acpi alsa amd64 bash-completion berkdb bitmap-fonts bzlib cdr crypt cups curl dvd dvdread exif fam flac font-server foomaticdb gdbm gif gpm gtk gtk2 imagemagick imlib ipv6 jp2 jpeg libwww lm_sensors lzw lzw-tiff mad motif mp3 ncurses network nls nptl nptlonly ogg oggvorbis opengl pam pda perl png ppds python qt qtmt readline rtc sdk spell ssl sysfs tcpd tetex threads tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xfce4 xine xml xml2 xmms xpm xrandr xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Err, "mount a tape"? Well, I
Err, "mount a tape"? Well, I´m no expert on tapes but these are NOT block devices, so you cannot mount them...
In the kdat GUI, the only way one can enable the backup facility is to "mount" the tape using that option in the GUI. Notwithstanding your comments, the naming convention used by the GUI for the naming of the actions it has stands, even if it may be questionable... ;) Unless the "mount action" is done, you can't backup. So that would make the program ... errm ... useless?! Thus it is vital to the functionality of the program to be able to perform the "mount action" on the tape, even if it is not really "mount /dev/st0 /mnt/tape", which you point out is incorrect, and not get hung up on the terminology they used.
Hmm, OK - let
Hmm, OK - let´s mount character devices with KDE, maybe we will get Kinux instead of Linux one day. Meanwhile, I´d suggest using some actually working utils, like tar.
Unfortunately kdat is not actively maintained and these problems are frequent, e.g.: http://bugs.kde.org/show_bug.cgi?id=72232 We cannot do much to help.
*** Bug 93195 has been marked as a duplicate of this bug. ***
*** Bug 93197 has been marked as a duplicate of this bug. ***
*** Bug 93199 has been marked as a duplicate of this bug. ***