Version: 2.0.1 (using KDE KDE 3.3.1) Installed from: Gentoo Packages Compiler: Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9 i686) Linux 2.6.9 #1 SMP Mon Dec 6 10:21:48 CET 2004 i686 Intel(R) Xeon(TM) CPU 2.66GHz GenuineIntel GNU/Linux OS: Linux i have a VXAtape from IBM... i can write and read over /dev/st0 (with mt) but i cant use Kdat. because in the Options of Kdat i cant change the blocksize from my tape (1024 Bytes/80GB) the max. i could select is 99 byte. if i use a smaller size Kdat Crashes :-( is the 99 byte/block limit normal? Belial
The same problerm exists with DAT-Tape (but it worked previously. Harald
I reported the identical problem in bug report 111279 http://bugs.kde.org/show_bug.cgi?id=111279 The status of this bug should be changed to CONFIRMED
for users of Suse Pro 9.x, a workaround is to revert to an earlier version of kdeadmin3 - I got the rpm for kdeadmin3 v. 3.2.1-27.i586 (bundled with Suse Pro 9.1 and on CD #3) and installed it. The kdat version says 2.0.1 but *something* is different in this rpm since kdat does not limit the tape block size to 99 bytes. After reverting, I am ble to archive and restore as before (see my bug report 111279). The intallation does *not* seem to have broken anything else. During testing, I installed several *later* rpm versions of kdeadmin3 (eg - version numbers higher than 3.2.1-27.i586), none of which allowed kdat to have a blocksize > 99 bytes. Pick a mirror site from http://www.novell.com/products/linuxprofessional/downloads/ftp/int_mirrors.html to find the kdeadmin3 rpm version that will work.
*** Bug 111279 has been marked as a duplicate of this bug. ***
Created attachment 19512 [details] Fix 99 limit in "Tape block size" I put the max block size to 50000 because I don't know which value is the max.
The default block size in the code is 512*20 (10240) that is greater than 99. That make imposible to read tapes created with old versions of kdat and default block size.
*** Bug 126782 has been marked as a duplicate of this bug. ***
fixed with revision 850245