[SOLVED] Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
Thank you for all your help. Now I have solved my problem. I identified two problems which are not directly related I guess. 1. when using -M /dev/hdd -> mkisofs would hang up in an infinite loop (consume CPU), this only happen to 2.0.1 version, the latest pre-alpha version don't have this problme (I succeeded in making the iso image 2. when using -M /tmp/first.iso -> mkisofs hangs, enter 'S' status, do not consume CPU, this happen to both versions of mkisofs. Currently not sure if this is a bug. I lost first.iso file by removed it accidentally, thus no longer able to reproduce this problem. Using -M /dev/hdd plus latest mkisofs now I can burn the CDR just fine. Thank you! signature.asc Description: 这是信件的数 字签名部分
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
å¼ é?¡æ¦ <[EMAIL PROTECTED]> wrote: > å?¨ 2006-09-24æ?¥ç?? 21:24 +0200ï¼?Patrick Ohlyå??é??ï¼? > > On Sat, 2006-09-23 at 23:31 +0800, å¼ é?¡æ¦ wrote: > > > Do you think I should now try the alpha > > > versions? > > > > Yes, please do that. There have been cases where mkisofs ran into an > > endless loop - your's may or may not be the same bug. > > > > If it still fails, do you think you could compile with debug information > > and no optimization (usually done with configure CFLAGS=-g) and then > > attach to the hanging mkisofs with a debugger to find out where it hangs > > (ps -ef | grep mkisofs; gdb -p )? > > I tried the 'lastest' one version 2.01.01a16-pre. Still fail with the > same behavior. I am still trying to get a back trace. > > I don't think it's an endless loop now, because if I replace -M /dev/hdd > to -M /tmp/first.iso then no more CPU resource is taken, when it hangs, > it simply hangs. PS shows its status is 'S' (waiting for an event). > > Output follows: > [EMAIL PROTECTED]:/opt/schily> bin/mkisofs -v -v -C 0,204809 -M > /tmp/first.iso -old-root / -m .beagle -m Cache -m .Trash -m .thumbnails -m > music -m '*.avi' -r -iso-level 4 -V 20060923_zhangweiwu_backup ~zhangweiwu/ > > /tmp/second.iso > Warning: creating filesystem that does not conform to ISO-9660. > Warning: Creating ISO-9660:1999 (version 2) filesystem. > Warning: ISO-9660 filenames longer than 31 may cause buffer overflows in the > OS. > mkisofs 2.01.01a16 (i686-pc-linux-gnu) > Rock Ridge signatures found > Scanning /home/zhangweiwu/ > Scanning /home/zhangweiwu/.mc First a note: due to the more mature option parser I am using now instead of GNU getopt_long, you may now use -vv instead of -v -v If you believe it hangs whithout consuming CPU time, it cannot really be a problem in mkisofs. Possible debug methods: - Run "pstack " to see a stack trace of the program - Run "gcore " followed by "adb " followed by $c to see a strack trace. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
在 2006-09-24日的 21:24 +0200，Patrick Ohly写道：
> On Sat, 2006-09-23 at 23:31 +0800, 张韡武 wrote:
> > Do you think I should now try the alpha
> > versions?
>
> Yes, please do that. There have been cases where mkisofs ran into an
> endless loop - your's may or may not be the same bug.
>
> If it still fails, do you think you could compile with debug information
> and no optimization (usually done with configure CFLAGS=-g) and then
> attach to the hanging mkisofs with a debugger to find out where it hangs
> (ps -ef | grep mkisofs; gdb -p )?
I tried the 'lastest' one version 2.01.01a16-pre. Still fail with the
same behavior. I am still trying to get a back trace.
I don't think it's an endless loop now, because if I replace -M /dev/hdd
to -M /tmp/first.iso then no more CPU resource is taken, when it hangs,
it simply hangs. PS shows its status is 'S' (waiting for an event).
Output follows:
[EMAIL PROTECTED]:/opt/schily> bin/mkisofs -v -v -C 0,204809 -M /tmp/first.iso
-old-root / -m .beagle -m Cache -m .Trash -m .thumbnails -m music -m '*.avi' -r
-iso-level 4 -V 20060923_zhangweiwu_backup ~zhangweiwu/ > /tmp/second.iso
Warning: creating filesystem that does not conform to ISO-9660.
Warning: Creating ISO-9660:1999 (version 2) filesystem.
Warning: ISO-9660 filenames longer than 31 may cause buffer overflows in the OS.
mkisofs 2.01.01a16 (i686-pc-linux-gnu)
Rock Ridge signatures found
Scanning /home/zhangweiwu/
Scanning /home/zhangweiwu/.mc
Scanning /home/zhangweiwu/.qt
Scanning /home/zhangweiwu/bin
Scanning /home/zhangweiwu/bin/.svn
Scanning /home/zhangweiwu/bin/.svn/tmp
Scanning /home/zhangweiwu/bin/.svn/tmp/props
Scanning /home/zhangweiwu/bin/.svn/tmp/text-base
Scanning /home/zhangweiwu/bin/.svn/tmp/prop-base
Scanning /home/zhangweiwu/bin/.svn/tmp/wcprops
Scanning /home/zhangweiwu/bin/.svn/props
Scanning /home/zhangweiwu/bin/.svn/text-base
Scanning /home/zhangweiwu/bin/.svn/prop-base
Scanning /home/zhangweiwu/bin/.svn/wcprops
Scanning /home/zhangweiwu/.dia
Scanning /home/zhangweiwu/.dia/objects
Scanning /home/zhangweiwu/.dia/shapes
Scanning /home/zhangweiwu/.dia/sheets
Scanning /home/zhangweiwu/.eva
Scanning /home/zhangweiwu/.kde
Scanning /home/zhangweiwu/.kde/share
Scanning /home/zhangweiwu/.kde/share/apps
Scanning /home/zhangweiwu/.kde/share/apps/k3b
Scanning /home/zhangweiwu/.kde/share/apps/k3b/temp
Scanning /home/zhangweiwu/.kde/share/apps/kfm
Scanning /home/zhangweiwu/.kde/share/apps/kfm/bookmarks
Scanning /home/zhangweiwu/.kde/share/apps/kabc
Scanning /home/zhangweiwu/.kde/share/apps/kssl
Scanning /home/zhangweiwu/.kde/share/apps/khtml
Scanning /home/zhangweiwu/.kde/share/apps/kconf_update
Scanning /home/zhangweiwu/.kde/share/apps/kconf_update/log
Scanning /home/zhangweiwu/.kde/share/apps/drkonqi
Scanning /home/zhangweiwu/.kde/share/apps/khelpcenter
Scanning /home/zhangweiwu/.kde/share/apps/khelpcenter/index
Scanning /home/zhangweiwu/.kde/share/apps/kwallet
Scanning /home/zhangweiwu/.kde/share/apps/RecentDocuments
Scanning /home/zhangweiwu/.kde/share/apps/kcookiejar
Scanning /home/zhangweiwu/.kde/share/apps/kopete
Scanning /home/zhangweiwu/.kde/share/apps/kopete/msnpictures
Scanning /home/zhangweiwu/.kde/share/apps/ktouch
Scanning /home/zhangweiwu/.kde/share/apps/konqueror
Scanning /home/zhangweiwu/.kde/share/mimelnk
Scanning /home/zhangweiwu/.kde/share/applnk
Scanning /home/zhangweiwu/.kde/share/config
Scanning /home/zhangweiwu/.kde/share/config/session
Scanning /home/zhangweiwu/.kde/share/config/colors
Scanning /home/zhangweiwu/.kde/share/config/kresources
Scanning /home/zhangweiwu/.kde/share/config/kresources/contact
Scanning /home/zhangweiwu/.kde/share/servicetypes
Scanning /home/zhangweiwu/.kde/share/services
Scanning /home/zhangweiwu/.nvu
Scanning /home/zhangweiwu/.nvu/v4ytmu7y.default
Scanning /home/zhangweiwu/.nvu/v4ytmu7y.default/US
Scanning /home/zhangweiwu/.nvu/v4ytmu7y.default/chrome
Scanning /home/zhangweiwu/.nvu/v4ytmu7y.default/extensions
Scanning
/home/zhangweiwu/.nvu/v4ytmu7y.default/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Scanning /home/zhangweiwu/.pan
Scanning /home/zhangweiwu/.pan/messages
Scanning /home/zhangweiwu/.pan/messages/cache
Scanning /home/zhangweiwu/.pan/messages/folders
Scanning /home/zhangweiwu/.pan/messages/folders/pan.迟后发送
Scanning /home/zhangweiwu/.pan/messages/folders/pan.发送
Scanning /home/zhangweiwu/.pan/freenews.netfront.net
Scanning /home/zhangweiwu/.w3m
Scanning /home/zhangweiwu/.ssh
Scanning /home/zhangweiwu/.vnc
Scanning /home/zhangweiwu/.stardict
Scanning /home/zhangweiwu/.cddb
Scanning /home/zhangweiwu/.cddb/data
Scanning /home/zhangweiwu/.cddb/folk
Scanning /home/zhangweiwu/.cddb/jazz
Scanning /home/zhangweiwu/.cddb/misc
Scanning /home/zhangweiwu/.cddb/rock
Scanning /home/zhangweiwu/.cddb/country
Scanning /home/zhangweiwu/.cddb/blues
Scanning /home/zhangweiwu/.cddb/newage
Scanning /home/zhangweiwu/.cddb/reggae
Scanning /home/zhangweiwu/.cddb/classical
Scanning /home/zhangweiwu/.cddb/soundtrack
Scanning /home/zhangweiwu/.gaim
Scanning /home/zhangweiwu/
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
Patrick Ohly <[EMAIL PROTECTED]> wrote: > On Sat, 2006-09-23 at 23:31 +0800, å¼ é?¡æ¦ wrote: > > Do you think I should now try the alpha > > versions? > > Yes, please do that. There have been cases where mkisofs ran into an > endless loop - your's may or may not be the same bug. And please test at least the intermediate version 2.01.01a16-pre The last release had an uninitialized variable *) and may do anything. *) due do the unclean historic design and a code restructuring. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
On Sat, 2006-09-23 at 23:31 +0800, 张韡武 wrote:
> Do you think I should now try the alpha
> versions?
Yes, please do that. There have been cases where mkisofs ran into an
endless loop - your's may or may not be the same bug.
If it still fails, do you think you could compile with debug information
and no optimization (usually done with configure CFLAGS=-g) and then
attach to the hanging mkisofs with a debugger to find out where it hangs
(ps -ef | grep mkisofs; gdb -p )?
A stack back trace ("where" in gdb) and some information where it loops
would help ("next" or "step" to single-step).
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
Joerg Schilling wrote: å¼ é?¡æ¦ <[EMAIL PROTECTED]> wrote: Further report in case it is helpful for debugging it: Because I am a bit in hurry (now is 23:55, better finish today's backup before 00:00) I tried to issue command to mkisofs replacing '-M /dev/hdd' with '-M /tmp/first.iso' where first.iso is the iso image for the CDR I burnt first time. By doing so I can separate the mkisofs failure with possible DVD-RW driver problem (because driver is not used when doing this mkisofs). The behavior: mkisofs starts to run, and hang pretty soon there, taking up NO CPU RESOURCE. It simply hang there. Ctrl+C and TERM signal is ignored, KILL signal cause it to quit. In any case, it is impossible to help you as long as you use this 2 year old outdated version. I can only help if you first test the latest version. 2.0.1 IS the latest rellease version... unless you put the later releases somewhere else. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
å¼ é?¡æ¦ <[EMAIL PROTECTED]> wrote: > > Further report in case it is helpful for debugging it: > > Because I am a bit in hurry (now is 23:55, better finish today's backup > before 00:00) I tried to issue command to mkisofs replacing > '-M /dev/hdd' with '-M /tmp/first.iso' where first.iso is the iso image > for the CDR I burnt first time. > > By doing so I can separate the mkisofs failure with possible DVD-RW > driver problem (because driver is not used when doing this mkisofs). > > The behavior: mkisofs starts to run, and hang pretty soon there, taking > up NO CPU RESOURCE. It simply hang there. Ctrl+C and TERM signal is > ignored, KILL signal cause it to quit. In any case, it is impossible to help you as long as you use this 2 year old outdated version. I can only help if you first test the latest version. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
å¼ é?¡æ¦ <[EMAIL PROTECTED]> wrote: > > > Then mkisofs start working, reading CDR for 10 seconds, then hang there. > > > top(1) shows mkisofs uses 100% CPU resource. First I thought it's simply > > > making the image, I left the computer there for 10 hours and it's still > > > computing, then I think probably it is a bug, mkisofs should not take so > > > long time to make the image. > > > > You are most likely using an extremely outdated version of mkisofs > > > > > > http://cdrecord.berlios.de/old/private/problems.html > > I don't think so... from the typescript you can see I am using 2.0.1 You are using a two year old version which is _definitely_ outdated! http://cdrecord.berlios.de/old/private/problems.html Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
在 2006-09-23六的 23:31 +0800，张韡武写道： > 在 2006-09-23六的 11:15 +0200，Joerg Schilling写道： > > <[EMAIL PROTECTED]> wrote: > > > > > Hello. I actually encounter this problem on SuSE linux, but I am pretty > > > sure I can reach the mkisofs authors much easier on this list, as this > > > could be a bug report, it's important to reach the authors/maintainers. > > > > > > I managed to learn to use -old-root to create CDR with only updated > > > files, see my previous post (attached at the end of this email). Here is > > > how to reproduce this 'bug': > > > > > > insert an empty CDR, do this > > > > > > [EMAIL PROTECTED]:~> mkisofs -r -iso-level 4 -m .beagle -V > > > 20060922_zhangweiwu_backup \ > > >-m Cache -m .Trash -m .thumbnails -m music -m '*.avi' -o > > > /tmp/zhangweiwu.iso ~ > > > > > > The first session of multi-session disc is made. The next day, do this: > > > > > > [EMAIL PROTECTED]:~> mkisofs -C `cdrecord dev=/dev/hdd -msinfo` -M > > > /dev/hdd -old-root / \ > > >-m .beagle -m Cache -m .Trash -m .thumbnails -m music -m '*.avi' \ > > >-r -iso-level 4 -V 20060923_zhangweiwu_backup -o /tmp/zhangweiwu.iso ~ > > > > > > Then mkisofs start working, reading CDR for 10 seconds, then hang there. > > > top(1) shows mkisofs uses 100% CPU resource. First I thought it's simply > > > making the image, I left the computer there for 10 hours and it's still > > > computing, then I think probably it is a bug, mkisofs should not take so > > > long time to make the image. > > > > You are most likely using an extremely outdated version of mkisofs > > > > > > http://cdrecord.berlios.de/old/private/problems.html > > I don't think so... from the typescript you can see I am using 2.0.1 > which as far as I know is the latest release version. I also checked > ftp://ftp.berlios.de/pub/cdrecord where it seems cdrtools-2.0.1 is the > latest package available for download. I cannot read the German part of > that known problems page, and the English part doesn't seem to cover > this problem. > > Thank you for the reply. Do you think I should now try the alpha > versions? I can surely understand maintaining such software package must > be a lot of work and you are pretty busy. However my current skill level > makes me feel more comfortable with pre-built packages... Further report in case it is helpful for debugging it: Because I am a bit in hurry (now is 23:55, better finish today's backup before 00:00) I tried to issue command to mkisofs replacing '-M /dev/hdd' with '-M /tmp/first.iso' where first.iso is the iso image for the CDR I burnt first time. By doing so I can separate the mkisofs failure with possible DVD-RW driver problem (because driver is not used when doing this mkisofs). The behavior: mkisofs starts to run, and hang pretty soon there, taking up NO CPU RESOURCE. It simply hang there. Ctrl+C and TERM signal is ignored, KILL signal cause it to quit. signature.asc Description: 这是信件的数 字签名部分
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
在 2006-09-23六的 11:15 +0200，Joerg Schilling写道： > <[EMAIL PROTECTED]> wrote: > > > Hello. I actually encounter this problem on SuSE linux, but I am pretty > > sure I can reach the mkisofs authors much easier on this list, as this > > could be a bug report, it's important to reach the authors/maintainers. > > > > I managed to learn to use -old-root to create CDR with only updated > > files, see my previous post (attached at the end of this email). Here is > > how to reproduce this 'bug': > > > > insert an empty CDR, do this > > > > [EMAIL PROTECTED]:~> mkisofs -r -iso-level 4 -m .beagle -V > > 20060922_zhangweiwu_backup \ > >-m Cache -m .Trash -m .thumbnails -m music -m '*.avi' -o > > /tmp/zhangweiwu.iso ~ > > > > The first session of multi-session disc is made. The next day, do this: > > > > [EMAIL PROTECTED]:~> mkisofs -C `cdrecord dev=/dev/hdd -msinfo` -M /dev/hdd > > -old-root / \ > >-m .beagle -m Cache -m .Trash -m .thumbnails -m music -m '*.avi' \ > >-r -iso-level 4 -V 20060923_zhangweiwu_backup -o /tmp/zhangweiwu.iso ~ > > > > Then mkisofs start working, reading CDR for 10 seconds, then hang there. > > top(1) shows mkisofs uses 100% CPU resource. First I thought it's simply > > making the image, I left the computer there for 10 hours and it's still > > computing, then I think probably it is a bug, mkisofs should not take so > > long time to make the image. > > You are most likely using an extremely outdated version of mkisofs > > > http://cdrecord.berlios.de/old/private/problems.html I don't think so... from the typescript you can see I am using 2.0.1 which as far as I know is the latest release version. I also checked ftp://ftp.berlios.de/pub/cdrecord where it seems cdrtools-2.0.1 is the latest package available for download. I cannot read the German part of that known problems page, and the English part doesn't seem to cover this problem. Thank you for the reply. Do you think I should now try the alpha versions? I can surely understand maintaining such software package must be a lot of work and you are pretty busy. However my current skill level makes me feel more comfortable with pre-built packages... signature.asc Description: 这是信件的数 字签名部分
Re: mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
å¼ é?¡æ¦ <[EMAIL PROTECTED]> wrote: > Hello. I actually encounter this problem on SuSE linux, but I am pretty > sure I can reach the mkisofs authors much easier on this list, as this > could be a bug report, it's important to reach the authors/maintainers. > > I managed to learn to use -old-root to create CDR with only updated > files, see my previous post (attached at the end of this email). Here is > how to reproduce this 'bug': > > insert an empty CDR, do this > > [EMAIL PROTECTED]:~> mkisofs -r -iso-level 4 -m .beagle -V > 20060922_zhangweiwu_backup \ >-m Cache -m .Trash -m .thumbnails -m music -m '*.avi' -o > /tmp/zhangweiwu.iso ~ > > The first session of multi-session disc is made. The next day, do this: > > [EMAIL PROTECTED]:~> mkisofs -C `cdrecord dev=/dev/hdd -msinfo` -M /dev/hdd > -old-root / \ >-m .beagle -m Cache -m .Trash -m .thumbnails -m music -m '*.avi' \ >-r -iso-level 4 -V 20060923_zhangweiwu_backup -o /tmp/zhangweiwu.iso ~ > > Then mkisofs start working, reading CDR for 10 seconds, then hang there. > top(1) shows mkisofs uses 100% CPU resource. First I thought it's simply > making the image, I left the computer there for 10 hours and it's still > computing, then I think probably it is a bug, mkisofs should not take so > long time to make the image. You are most likely using an extremely outdated version of mkisofs http://cdrecord.berlios.de/old/private/problems.html Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mkisofs bug? creating cdrom image for bulk files with -old-root -> enter infinite loop?
Hello. I actually encounter this problem on SuSE linux, but I am pretty sure I can reach the mkisofs authors much easier on this list, as this could be a bug report, it's important to reach the authors/maintainers. I managed to learn to use -old-root to create CDR with only updated files, see my previous post (attached at the end of this email). Here is how to reproduce this 'bug': insert an empty CDR, do this [EMAIL PROTECTED]:~> mkisofs -r -iso-level 4 -m .beagle -V 20060922_zhangweiwu_backup \ -m Cache -m .Trash -m .thumbnails -m music -m '*.avi' -o /tmp/zhangweiwu.iso ~ The first session of multi-session disc is made. The next day, do this: [EMAIL PROTECTED]:~> mkisofs -C `cdrecord dev=/dev/hdd -msinfo` -M /dev/hdd -old-root / \ -m .beagle -m Cache -m .Trash -m .thumbnails -m music -m '*.avi' \ -r -iso-level 4 -V 20060923_zhangweiwu_backup -o /tmp/zhangweiwu.iso ~ Then mkisofs start working, reading CDR for 10 seconds, then hang there. top(1) shows mkisofs uses 100% CPU resource. First I thought it's simply making the image, I left the computer there for 10 hours and it's still computing, then I think probably it is a bug, mkisofs should not take so long time to make the image. mkisofs only read the CDR in the beginning, then in the following hours it doesn't seems to be reading the CDR; besides, both CDR and the DVD-RW driver are new, thus I guess it's not related to CDR performance. I added two '-v' parameter to the commandline and get the attached typescript (using script(1)) for you for debugging purpose. In that typescript I used Ctrl+C to break mkisofs after 10 hours. Total number of files recorded on CDR is some 1000 files. Please let me know what else should I provide to help you get the bug tracked/reproduced. for me it is always reproducible. 在 2006-09-17日的 15:19 +0800，张韡武写道： > Hello. I was a happy user of Nero on Windows, though I am not a happy > Windows user and now switched to Linux. My problem is I cannot backup > using my favorite way anymore: > > I used to back up our project files (devided into 8 categories, each > category have about 200MB files) on daily basis. This is how I do it on > Windows. > > 1. on monday, prepare 8 empty CDR, one for each category, back up > everything (each CDR take 200MB with 400MB free space); > 2. on the following days, launch Nero and select continue > multi-session, it will AUTOMATICALLY add every file added in > that day or replaced in that day, removing every file removed > that day, and create another session for only the changed > documents. Every day around 30MB files are changed in each > category, every CDR is filled with an 30MB session. > 3. repeat this for one week, on the weekend, store these CDR > backups and prepare new blank CDR for the next week. > > This is actually very convenient for me, each CDR is labeled with week > number and project category name. If the manager ask for files on Jan > 12th in the training project, I go to find the CDR in training project > backup CDs, find that week's backup, figure out 12th is a Thursday, thus > mount the 4th session. I actually have been doing this for years. Now I > switched to inux and no longer know how to do the same operation. > k3b doesn't automatically replace old files when I continue > multi-session disc, besides, there seems to be no way to remove a file > from a previous session, right click a file in an imported session in > k3b, there is no option to remove it. > > I am not afraid of commandline, thus if it is possible at all to do the > backup the same mechanism I did on Windows, I would love to sit down and > write some backup scripts with mkisofs/cdrecord. However as I read > through the manual of both mkisofs and cdrecord, there are no clear > instructions on how to modify the directory structure of previous > session and apply it to current session. E.g. in mkisofs -C and -M can > be used to import previous session, but there are no written instruction > on how to remove a file after imported previous session. > > Can you please let me know if it is possible at all to manipulate the > backup operation in Linux? If possible, where can I look for docs on how > to generate proper iso image with mkisofs for a session modified from > previous session (more specifically, how to delete a file from previous > session)? > > Thank you in advance! > > P.S. I also tried nero Linux version, for two reasons I cannot use it > yet: first it doesn't install at all (some errors), second, it seems not > able to operate through SSH, since after switched to Linux we separated > file server to the server room 50m from my office, I would prefer to sit > in the office to do the backup by using scripts and ssh. > > P.S. Please redirect me to another proper mailing list if you think I'd > better post questions there. I am a bit afraid this question is pretty > into the depth of mkisofs and should go
