[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 w
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 o
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.
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 and
> > > > 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
> > tr
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 a
> > 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 di
[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
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 c
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
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
[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 ena
> 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
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. I
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 supp
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.
[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-9
[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 li
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 mach
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
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]
wit
[EMAIL PROTECTED] wrote:
Bill Davidsen wrote:
Unless you have the luxury of taking the system to single user mode, it
is always possible that you should have a file change.
Yep. The backup should be done in situations where
changes either don't occur or don't matter for the
Hi,
> Bill Davidsen wrote:
>
> Unless you have the luxury of taking the system to single user mode, it
> is always possible that you should have a file change.
Yep. The backup should be done in situations where
changes either don't occur or don't matter for the
quality of the backup.
How to achi
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
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
[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 whe
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 requir
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 st
[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
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 sh
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 p
[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 t
> > 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
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 re
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 su
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 have
Hi,
> Then you know that mkisofs does not try to read
> zero sized files.
This might be true if mkisofs is aware of the 0 size.
But in my problem situation, the size known to mkisofs
is not the current size of the file when it comes to reading.
I can prove : in this situation even 0 sized files
[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 f
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
[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 fo
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 res
[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
>
>
> Th
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
43 matches
Mail list logo