Image recovery: Recovering fragmented image files from fla..

Hans-Peter Diettrich <DrDiettrich1.RemoveThis@aol.com> writes:
> Phil Carmody wrote:
>
> > Are you sticking by your previous """
> > Deleted files are
> > overwritten only after the medium is full.
> > """ claim?
>
> Yes, of course :-]
>
> > If so, consider this sequence:
> > 1) Create A
> > 2) Create B
> > 3) Delete A
> > 4) Create C
> > After stage 3, what is the lowest free cluster? Is it after B, or
> > where A was?
>
> Why bother with the lowest free cluster?
>
> Of course it's where A has been, but that doesn't affect the write
> pointer, which stays behind B.

Each of the above operations is atomic, so what the fuck is a write
pointer? You're barely making sense, so it's hard to argue against
you.

The FAT32 system apparently (see posts by other posters upthread)
writes each new file at the lowest cluster it can. That's from
where A has been. This is in agreement with all the prior FAT
systems that I have been familiar with.

If you can't work out how and where you're wrong given this
information, I simply don't have the time and patience to spoon
feed you any more. Perhaps try on comp.i.dont.have.a.clue ?

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration
 >> Stay informed about: Image recovery: Recovering fragmented image files from fla.. 

Phil Carmody wrote:

> Each of the above operations is atomic, so what the fuck is a write
> pointer? You're barely making sense, so it's hard to argue against
> you.

You have read about FSInfo.FSI_Nxt_Free?

Isn't that a write pointer?


> The FAT32 system apparently (see posts by other posters upthread)
> writes each new file at the lowest cluster it can.

So you think that the system scans the FAT, each time a cluster has to
be allocated to an file or directory?

> This is in agreement with all the prior FAT
> systems that I have been familiar with.

Then familiarize with the new features of FAT32, before posting nonsense ;-]

DoDi
 >> Stay informed about: Image recovery: Recovering fragmented image files from fla.. 

> Then familiarize with the new features of FAT32, before posting nonsense ;-]

And if you took the time to study how FSI_Nxt_Free is implemented, you wouldn't keep posting stuff like this. FSI_Nxt_Free points to
the lowest available cluster. Nothing more & nothing less. Nowhere is is said that there can't be any used clusters after this. Get
it?

--
cmyk
 >> Stay informed about: Image recovery: Recovering fragmented image files from fla.. 

cmyk wrote:

>> Then familiarize with the new features of FAT32, before posting
>> nonsense ;-]
>
>
> And if you took the time to study how FSI_Nxt_Free is implemented, you
> wouldn't keep posting stuff like this. FSI_Nxt_Free points to the lowest
> available cluster. Nothing more & nothing less. Nowhere is is said that
> there can't be any used clusters after this. Get it?

"Typically this value is set to the last cluster number that the driver
allocated. "

Which part of that description did you not understand?

Hint: "allocated" is not "released".

DoDi
 >> Stay informed about: Image recovery: Recovering fragmented image files from fla.. 

Hans-Peter Diettrich <DrDiettrich1 DeleteThis @aol.com> writes:
> Phil Carmody wrote:
>
> > Each of the above operations is atomic, so what the fuck is a write
> > pointer? You're barely making sense, so it's hard to argue against
> > you.
>
> You have read about FSInfo.FSI_Nxt_Free?
>
> Isn't that a write pointer?

Given that one term has already been coined for it, there's
no need to coin another one. Economy of nomenclature.

> > The FAT32 system apparently (see posts by other posters upthread)
> > writes each new file at the lowest cluster it can.
>
> So you think that the system scans the FAT, each time a cluster has to
> be allocated to an file or directory?

My god, you really are as stupid as I first suspected!

No I do not think that at all.

What on earth made you think a scan would be required every time?
That's what maintaining such an index is for, so you don't have
to scan. Think about which operations could make that index change,
and whether the system knows what it would change to after
completion of those operations.

> > This is in agreement with all the prior FAT systems that I have been
> > familiar with.
>
> Then familiarize with the new features of FAT32, before posting nonsense ;-]

Care to provide citations for where the standards deviate in
this regard?

Damn, I'd forgotten that I said I wasn't going to waste time
spoon feeding someone who has painted himself from head to toe
in KlooRezist. Due to lack of compression content, I'm removing
comp.compression from followups so I don't have to suffer your
no-doubt inane and ill-conceived reply.

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration
 >> Stay informed about: Image recovery: Recovering fragmented image files from fla.. 

"Hans-Peter Diettrich" <DrDiettrich1 RemoveThis @aol.com> wrote in message news:5khhujF3boegU1@mid.individual.net...
> "Typically this value is set to the last cluster number that the driver allocated. "

Which only goes to prove my point - 'typically' is not mandated behaviour and, as I said from the outset, that "is a task for the OS
or, perhaps, the media controller" - FAT32 does not do this of itself. Why don't you pay attention???

--
cmyk
 >> Stay informed about: Image recovery: Recovering fragmented image files from fla.. 

"cmyk" <nowhere.RemoveThis@ether.net> writes:
> "Hans-Peter Diettrich" <DrDiettrich1.RemoveThis@aol.com> wrote in message news:5khhujF3boegU1@mid.individual.net...
> > "Typically this value is set to the last cluster number that the driver allocated. "
>
> Which only goes to prove my point - 'typically' is not mandated
> behaviour and, as I said from the outset, that "is a task for the OS
> or, perhaps, the media controller" - FAT32 does not do this of
> itself. Why don't you pay attention???

Ah, so they're covering their backs. Their "typical" behaviour
is of no practical use in a scenario where the total amount of
data written is larger than the capacity of the storage medium,
and if anyone complains about that they can just say "well,
we didn't force you to use that technique".

OK, I admit it, MS have made their file system design worse
over time in this regard. However, they're at least not hiding
the fact.

However, as you say, they certainly aren't mandating the
behaviour claimed by HPD.

Didn't IBM teach them about proper file systems over a decade
ago?

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration
 >> Stay informed about: Image recovery: Recovering fragmented image files from fla..