Volker Kuhlmann [EMAIL PROTECTED] wrote:
Of course, checkreading has to be done by a second
computer meanwhile.
Why do you believe that there is a difference?
The first computer might not have enough bandwidth for burning and
verifying. Or only a burner, not a burner
[EMAIL PROTECTED] wrote:
And how is this related to a filesystem snapshot?
Volker Kuhlmann wrote :
Not, I believe he was talking about checkreading the burnt disks, sorry
if I misunderstood.
Possibly my fault.
I meant to be talking about the large time window of
a real world DVD (or
Hi,
I wrote:
Of course, checkreading has to be done by a second
computer meanwhile.
Joerg Schilling wrote :
Why do you believe that there is a difference?
Volker Kuhlmann wrote :
The first computer might not have enough bandwidth for burning and
verifying.
My own one can feed via
[EMAIL PROTECTED] wrote:
If you are doing real reliable backups, you can't because
you cant't have a Filesystem snapshot that survives a reboot.
With the agile system files in a Linux root filesystem
one should not do that. But that are at most a few GB.
Do you mean that Linux has no
Of course, checkreading has to be done by a second
computer meanwhile.
Why do you believe that there is a difference?
The first computer might not have enough bandwidth for burning and
verifying. Or only a burner, not a burner and a reader. Also, when
trying to ensure that a burned disk is
Volker Kuhlmann [EMAIL PROTECTED] wrote:
Of course, checkreading has to be done by a second
computer meanwhile.
Why do you believe that there is a difference?
The first computer might not have enough bandwidth for burning and
verifying. Or only a burner, not a burner and a reader.
Of course, checkreading has to be done by a second
computer meanwhile.
Why do you believe that there is a difference?
The first computer might not have enough bandwidth for burning and
verifying. Or only a burner, not a burner and a reader. Also, when
trying to ensure that a
Volker Kuhlmann wrote:
Of course, checkreading has to be done by a second
computer meanwhile.
Why do you believe that there is a difference?
The first computer might not have enough bandwidth for burning and
verifying. Or only a burner, not a burner
[EMAIL PROTECTED] wrote:
If you do this with mkisofs or afio which are no backup
tools, this may be OK, but if you do this with a program like star
that includes backup support, it is questionable.
It opens a way to use ISO-9660 (with all pros and cons)
as storage format. It enabled me
Bill Davidsen [EMAIL PROTECTED] wrote:
True, nor would the binary files for x86 execute on SPARC. Therefore you
would restore a system backup on a compatible system. But if the system
backup isn't bootable it isn't a backup, because you have to load the
O/S from something else.
I think
Volker Kuhlmann [EMAIL PROTECTED] wrote:
Mastering an iso9660 is an atomic operation. You could copy all files
meant to go onto it to a new location first, that gives you a second
chance for files which were troublesome the first time.
If the tool you use to copy does not notice a change
Hi,
For example : what happens if you have to shut
down your machine after half a backup of 50 CDs
is done.
Can you do the rest next day ? Without starting
new (and not getting done until evening again) ?
If you are doing real reliable backups, you can't because
you cant't have a
Bill Davidsen [EMAIL PROTECTED] wrote:
It's just that a reasonable person does not backup agile
parts of the disk via mkisofs directly. (I was doing an
experiment for evaluating a user's error message. So i
did things which i never had done on my own before.)
Unless you have the
Bill Davidsen [EMAIL PROTECTED] wrote:
Apologies, an entire sentence was deleted from the above by finger
check. The issue raised is that star backups are not bootable on any
machine I've found, and are unsuitable for system backups for that
reason. ISO CDs are bootable on many machines,
[EMAIL PROTECTED] wrote:
- Damaged CPIO archives are much harder to recover than
tar archives.
afio does a good job with that.
But this is very time consuming as it needs to step forward
in 2 byte units while tar may do it in 512 byte units.
- The POSIX cpio format is limited
[EMAIL PROTECTED] wrote:
Since quite a lot of years we have to be thankful
to Joerg Schilling who provides the only general
ISO-9660 formatter and CD-RW writer software for
Linux systems of nearly any age.
Although he seems not to enjoy it much.
Well, in 1995 I started to write a ISO-9660
Greg Wooledge [EMAIL PROTECTED] wrote:
On Mon, Aug 08, 2005 at 05:56:02PM +0200, Joerg Schilling wrote:
P.S.: which recent OS does not come with star?
Microsoft Windows. But it *can* read ISO 9660 CDs... which makes
backups using mkisofs + cdrecord quite handy for many situations.
Star
Hi,
[EMAIL PROTECTED] wrote :
my own software is the backup utility and star is the
media image formatter
Joerg Schilling wrote :
If you do this with mkisofs or afio which are no backup
tools, this may be OK, but if you do this with a program like star
that includes backup support, it
Joerg Schilling wrote:
Bill Davidsen [EMAIL PROTECTED] wrote:
Apologies, an entire sentence was deleted from the above by finger
check. The issue raised is that star backups are not bootable on any
machine I've found, and are unsuitable for "system backups" for that
reason.
Padding a shrunk file is a real bad idea.
What other options do you have? That particular file has changed, you
can't get a good backup of it now. You are in the middle of writing out
an iso9660 stream, the directory (file size + location) info has already
been written and you can't seek() back
On Mon, Aug 08, 2005 at 05:56:02PM +0200, Joerg Schilling wrote:
P.S.: which recent OS does not come with star?
Microsoft Windows. But it *can* read ISO 9660 CDs... which makes
backups using mkisofs + cdrecord quite handy for many situations.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Joerg Schilling wrote:
Bill Davidsen [EMAIL PROTECTED] wrote:
I would need to rethink the problem.
Here's a thought on that, if the read length is not the same as the
expected length, the error is really file size changed during read and
the current length can be found with
Bill Davidsen [EMAIL PROTECTED] wrote:
If you like to do backups, use apropriate tools (e.g. star).
I have looked through the man pages and even the source for star, and
don't see how to create ISO9660 images. It seems only to be able to
create its own format backups, which require
[EMAIL PROTECTED] wrote:
Hi,
Bill Davidsen wrote:
Since I never get an error I would suspect that the change is not
detected, the only question is if the data saved is only that which was
originally expected, or all available.
To my theory the effect should occur
Bill Davidsen wrote:
I would have
loved to have star 15 years ago. I wouldn't use any
solution today which required reading the whole data set to extract
things, was not portable, and which is not cost effective in terms of
timeto recovery. Star represents the best implementation ever written
Hi,
Joerg Schilling wrote
of star-1.4.3 and online in
Any reason to test a version that is outdated since more than 3 years?
It was the youngest star-* archive which i could spot in
ftp://ftp.berlios.de/pub/star
I did not explore the alpha directory.
I'll use star-1.5a64 for the rest of my
Hi,
Joerg Schilling wrote:
If you like to do backups, use apropriate tools (e.g. star).
star should handle any issue that is relevent for backups.
Of course, star is limited to the support you get from the OS.
If you find anything reasonable that is not handled correctly,
you should send
[EMAIL PROTECTED] wrote:
Up to now, i found a typo and a truncated sentence in the man page
of star-1.4.3 and online in
Any reason to test a version that is outdated since more than 3 years?
http://cdrecord.berlios.de/old/private/man/star.html :
POSIX tar compatibilitx mode
The
Joerg Schilling wrote:
[EMAIL PROTECTED] wrote:
Hi,
many thanks for taking care of mkisofs
during all the years.
seterrno(EFBIG);
BTW: File too large is usually used to deal with the same situation
when writng to a device that is too small.
Do you
Bill Davidsen [EMAIL PROTECTED] wrote:
I would need to rethink the problem.
Here's a thought on that, if the read length is not the same as the
expected length, the error is really file size changed during read and
the current length can be found with stat() or similar. I'm surprised
Hi,
Bill Davidsen wrote:
Since I never get an error I would suspect that the change is not
detected, the only question is if the data saved is only that which was
originally expected, or all available.
To my theory the effect should occur whenever filesize div 32768
yields a lower result
If you like to do backups, use apropriate tools (e.g. star).
I will have to RTxy about star in order to find out
which of the challenges of backuping it promises to
handle.
Not your ease of retrieval requirement. Nothing which packs up your
files into any sort of container first will give
[EMAIL PROTECTED] wrote:
If you like to do backups, use apropriate tools (e.g. star).
I will have to RTxy about star in order to find out
which of the challenges of backuping it promises to
handle.
star should handle any issue that is relevent for backups.
Of course, star is limited to the
Volker Kuhlmann [EMAIL PROTECTED] wrote:
If you like to do backups, use apropriate tools (e.g. star).
I will have to RTxy about star in order to find out
which of the challenges of backuping it promises to
handle.
Not your ease of retrieval requirement. Nothing which packs up your
[EMAIL PROTECTED] wrote:
Hi,
Possibly one should resort to
EIO 5 /* I/O error */
This would be a bad idea.
Why that ?
Because this is a _real_ error from the hardware.
mkisofs: File too large. cannot read from '...'
might happen with a file that has 0
[EMAIL PROTECTED] wrote:
Hi Joerg,
i experienced an abort of mkisofs 2.01a34 which
-to my best knowledge- returned a 0 exit value.
A possible reason for this 0 exit value can be found in
the code of 2.01a34, 2.01 and 2.01.01a3 in :
mkisofs/write.c
libschily/comerr.c
The run of
Hi,
many thanks for taking care of mkisofs
during all the years.
seterrno(EFBIG);
BTW: File too large is usually used to deal with the same situation
when writng to a device that is too small.
Do you have an idea for a better errno?
Possibly one should resort
[EMAIL PROTECTED] wrote:
Hi,
many thanks for taking care of mkisofs
during all the years.
seterrno(EFBIG);
BTW: File too large is usually used to deal with the same situation
when writng to a device that is too small.
Do you have an idea for a better
Hi,
Possibly one should resort to
EIO 5 /* I/O error */
This would be a bad idea.
Why that ?
mkisofs: File too large. cannot read from '...'
might happen with a file that has 0 bytes.
No, it may not (RTSL).
Hey ! I did invest some effort in reading the source.
Hi Joerg,
i experienced an abort of mkisofs 2.01a34 which
-to my best knowledge- returned a 0 exit value.
A possible reason for this 0 exit value can be found in
the code of 2.01a34, 2.01 and 2.01.01a3 in :
mkisofs/write.c
libschily/comerr.c
The run of mkisofs aborted with these messages
40 matches
Mail list logo
