also sprach Andi Kleen <ak@xxxxxx> [2005.02.11.1400 +0100]:
> [Sorry but that was really explained multiple times. Read the
> archives again for more details. Here just quick explanation.]
I am only one of many people that are unable to find answers to
questions I posed in my email. Also, I am only one of many people
who are still totally confused about XFS' binary nulls.
My intention to write this post was simply to sum it all up and work
towards a better answer in the FAQ. I believe I stated this,
although maybe not clearly.
Please do not read this email as a flame or personal attack!
You will note that most of my email is a summary of what you just
told me. I only ask two questions, none of which you have answered.
I still very much appreciate your time, but please try to understand
where I am coming from. If you believe that this issue has been
sufficiently answered "many times", then I kindly ask you to point
me to such an explanation in the archives. I have searched myself
and I was not satisfied. And being a proponent of XFS whereever
I go, I am always being asked by people for an explanation because
they could not find a satisfiable one either.
So basically, what I summarised in my first post is correct from the
perspective of a user, right?
Let's assume that a truncating open() gets interrupted just after
the metadata are flushed and before the new contents makes it to the
disk. Then, the old file contents is still on the disk, but XFS
hides it behind a curtain of zeroes. How can I get at the original
data in such a case?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@xxxxxxxxxxx
micro$oft is to operating systems & security
what mcdonalds is to gourmet cuisine.
signature.asc
Description: Digital signature
|