If the limit is 64 the solution is to make a tar or the files and compress that with gz. Then burn the tar.gz to cd or dvd. I do this with antique dos all the time. Just be careful about the options to preserve dates, times and permissions on compression and for restore.

Thanks, I also do this but I wanted another copy that is easily browsable directly on the DVD. Thanks again, IG ________________________________________________________________ Lóerők, hengerek, igényre szabottan! http://jarmuapro.origo.hu/advancedSearch.do?cid=1&rid=1#chooseCategory

On Fri, 2006-08-11 at 21:02 +0200, Istvan Gabor wrote:

...

If the limit is 64 the solution is to make a tar or the files and compress that with gz. Then burn the tar.gz to cd or dvd. I do this with antique dos all the time. Just be careful about the options to preserve dates, times and permissions on compression and for restore.

Thanks,

I also do this but I wanted another copy that is easily browsable directly on the DVD.

While its more work in 9.x in 10.x Konqueror directly opens a targz as if it were a directory and you can browse and copy files, directories from there. -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/

On Thursday 10 August 2006 01:53, Carl William Spitzer IV wrote:

Oops forgot the example:

#!/bin/bash mount /dev/hda1 /windows/c/ vDate=`date +20%y-%m-%d` tar -zcvf Cdrive$vDate.tar.gz /windows/c echo $vDate umount windows/c/

An optimization note: Leave off the 'v' (verbose) option to tar to speed up your tar times. Input/Output (in this case output to the console) is one of the slowest things a computer can be forced to do. As an example of how this simple flag can speed things up, try the following in a console expanded to fill up your whole desktop: cd / find . Now shrink that console down to, say 1/4 the size of your screen and do it again: cd / find . It will run a lot faster the second time because of the way output and updating of the console window works. (It will also run faster because the OS cached many of the file entries during the first run, but even without that caching it will run faster in a smaller window.) Now try: cd / find . > /dev/null and you'll see that it runs a lot faster because output to /dev/null is a lot faster than output to a console. The exact reasons for this are detailed and technical, but essentially it's because the console window has to update it's whole visible area when it outputs a new line to the screen and the program which generates the output has to wait on the console to do that. The amount of time is trivial for most purposes but can indeed be non-trivial when running an app which generates a lot of output to "standard out" (the console, unless you redirect the output as we did in the last example). The moral of the story is: don't use the 'v' flag to tar unless you really need it, especially when doing a large tar (such as /windows/C). PS: and use date +%Y for a 4-year date instead of date +20%y, which isn't Y2100 compliant. :) -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts