On Thu, 2007-10-18 20:24:33 +0200, Joerg Schilling <[EMAIL PROTECTED]> wrote: > Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote: > > > If you like to compare this, you would need to either call star as "tar" > > > or tell star to be as insecure as GNU tar is. > > > > > > So test again with "star -no-fsync ..." > > > > Is `-no-fsync' the only difference? How much more secure does this > > make star over tar? My guestimation tells me that there's only really > > a difference in case of a system crash during/right after tarball > > extraction. > > I have seen unfixable (via fsck) filesystemn corruption on Linux after a > power outage a short time after extracting a bigger filesystem tree.
Yeah, old story. We've seen SIGSEGV'ing fscks, too. (Though I've
never seen that with Linux + ext[23].)
However, I think it's not tar's task to ensure that all data is
written to a stable medium. Tar has to ensure that, after exit()ing,
all files are ready to be accessed and match the expectation.
> If you like to evaluate the exit code of any tar, this only makes
> sense if the tar implementation calls fsync() before close(). If it
> does not call fsync(), a zero exit code does not grant anything.
It does grant me that if I start any filesystem operation (or mmap()
or whatever), this'll succeed. But I don't think it's tar's business
to mimic a database server or anything else that must be
"transactionally" safe. If you want that, maybe a data-journaling
or sync-mounted filesystem is what you actually want to deploy.
> Star (called under the name "star") implements other deviations from the
> behavior of the classical UNIX tar, e.g. different defaults for the unlink()
> setup in extract mode.
Hopefully it doesn't try to unlink() directories :->
MfG, JBG
--
Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481
Signature of: God put me on earth to accomplish a certain number of
the second : things. Right now I am so far behind I will never die.
signature.asc
Description: Digital signature
