late experiences with fat32

On 10/21/2015 02:32 PM, J. P. Gilliver (John) wrote:
In
I've seen fat systems be rendered useless by writing the data to a
slew of "chk" files

I _think_ you mean by it (them) writing the chk files to contain
"orphaned" data they find. [The _user_ can write chk files as much as
they like.] What NTFS systems do when they find orphaned data, I'm not
sure; maybe they never do find such.




Back in the days of Win9x (Fat 16 or 32) if there was a bad shut down
scandisk would run and usually fix everything...but not always.

It would give the user the option to write the recovered data to files
or discard it.

The problem is, once the "recovered" data was written to a .chk file the
user would soon see they were usually file fragments.


I never was able to piece them back together but a few times by
examining the headers and I could see what it was...then change the
extension to what it should have been.

I know a recovered some jpg's that way.



With NTFS, even on failing hard drives I've usually been able to save
most of the data due to the journaled nature of NTFS.

Bill Cunningham wrote:
"Paul" wrote in message
...

...

I'm just a little confused as to why a file. Like the one on my HD
disappeared. It wasn't open. Why would it have been in memory? It simply
vanished.

Bill

Maybe it took a small corruption in the file system,
followed by a CHKDSK you'd run, to cause it to disappear
when the corruption was corrected ?

Paul

[Default] On Thu, 22 Oct 2015 12:35:29 -0500, in
microsoft.public.windowsxp.general philo wrote:

On 10/21/2015 02:32 PM, J. P. Gilliver (John) wrote:
In
I've seen fat systems be rendered useless by writing the data to a
slew of "chk" files

I _think_ you mean by it (them) writing the chk files to contain
"orphaned" data they find. [The _user_ can write chk files as much as
they like.] What NTFS systems do when they find orphaned data, I'm not
sure; maybe they never do find such.




Back in the days of Win9x (Fat 16 or 32) if there was a bad shut down
scandisk would run and usually fix everything...but not always.

It would give the user the option to write the recovered data to files
or discard it.

The problem is, once the "recovered" data was written to a .chk file the
user would soon see they were usually file fragments.

This has turned out not to be about .chk files. For .chk files, see
my footnote **. With an early version of Forte Agent, earlier than
1.93, I guess, posts and replies and emails, those that were saved or
queued, when windows crashed and took Agent with it, were lost.

Things that I'd just written and had no other copy of. Eventually I
learned to close the Agent outbox frequently in order to actually save
the posts, and reopen it if necessary. If the outbox was closed to
begin with, I think I had to open it and close it to truly save the
posts.

But anyhow, scandisk would run like you say and make a bunch of chk
files (or maybe it was Norton's version of scandisk and the files
ended with another extension, iirc). and if I was lucky enough to
remember an unusal word or phrase, I would use the Norton file and
disk editor, and search the entire harddrive to find....Oh, I thought
this would be about .chk files. But as I type, my memory gets more
detailed and it's not**. Sorry.

Anyhow, I would use the editor to find the outbox part of the
harddrive and the lost posts would be adjacent to each other, and I
would determine the start and end addresses and copy the info out of
the drive, and then find what I was replying to and post my reply.

What a pain.

And at first I had a hard time convincing the Forte Agent people, at
least one of whom read the Agent newsgroup, that there was really such
a big bug. Well, maybe until they forced a crash and found out
directly

**But I did also spend a lot of time looking at .chk files, using the
NDOS utility LIST, and I found lots of recognizeable files, which were
usually complete, and started at the start of the .chk file, but which
ended some time before the .chk file ended. Those all turned out to
be non-data files that were undamaged by the crash.

I never was able to piece them back together but a few times by
examining the headers and I could see what it was...then change the
extension to what it should have been.

I know a recovered some jpg's that way.



With NTFS, even on failing hard drives I've usually been able to save
most of the data due to the journaled nature of NTFS.

"Paul" wrote in message
...

Maybe it took a small corruption in the file system,
followed by a CHKDSK you'd run, to cause it to disappear
when the corruption was corrected ?

Yes fat32 does that everytime the computer restarts. chkdsk.

Bill

"Bill Cunningham" wrote in message
...

"Paul" wrote in message
...

Maybe it took a small corruption in the file system,
followed by a CHKDSK you'd run, to cause it to disappear
when the corruption was corrected ?

Yes fat32 does that everytime the computer restarts. chkdsk.

So is that one of fat32's weaknesses?

Bill

[Default] On Thu, 22 Oct 2015 17:17:46 -0400, in
microsoft.public.windowsxp.general "Bill Cunningham"
wrote:


"Paul" wrote in message
...

Maybe it took a small corruption in the file system,
followed by a CHKDSK you'd run, to cause it to disappear
when the corruption was corrected ?

Yes fat32 does that everytime the computer restarts. chkdsk.

It does? Seems to me it only does that when a flag tells it that
there has been an error, mostly following a crash.

If you decide to skip chkdsk, that's not a complete rebuff and it
keeps asking you every time. But once you say yes and let it run, it
won't run again unless something goes wrong and it knows about it.

Bill

[Default] On Thu, 22 Oct 2015 17:15:16 -0400, in
microsoft.public.windowsxp.general Micky
wrote:



**But I did also spend a lot of time looking at .chk files, using the
NDOS utility LIST, and I found lots of recognizeable files, which were
usually complete, and started at the start of the .chk file, but which
ended some time before the .chk file ended. Those all turned out to
be non-data files that were undamaged by the crash.

I could tell the files were complete because they all started and
ended in the same way and many of them had their name inside the file.
I wish all system and program files did.

One time, in DOS I guess the directory was cross-linked -- could that
do it? -- and I deleted one directory and its subdirectory and then it
went after another directory that was higher and deleted about 70
files that were not under the first directory. Undelete found them
all and they were named ?in.com for example. and I didn't know what
the first letter should be, but in half of the cases, the name of the
file was inside the file. Others I identified, but that still left 2
20 which remained named by me ain, bin, cin.com, and maybe din, until
I left DOS behidn.

Bill Cunningham wrote:
"Paul" wrote in message
...

Maybe it took a small corruption in the file system,
followed by a CHKDSK you'd run, to cause it to disappear
when the corruption was corrected ?

Yes fat32 does that everytime the computer restarts. chkdsk.

Bill



https://technet.microsoft.com/en-us/.../bb490641.aspx

fsutil query dirty C:

*******

There are several things that can happen:

1) Requesting CHKDSK of the OS partition, causes the check
to be queued to a later time.

BootExecute registry key
Autochk or similar

Multiple lines of text can be contained in the BootExecute key.
Since BootExecute is executed early, some simple kinds of malware
used to add a line to it.

2) A crash causes the Dirty bit to be set. The Dirty bit
is detected by checking at startup. There is a Dirty bit
per partition.

3) The user uses FSUTIL to set the dirty bit, similar to (2).
This is sometimes done on purpose by stuff. For example, mounting
a partition from Linux, Linux can set the Dirty bit, as a "signal"
to Windows to clean up a potential mess. This is because the
Linux people don't want to have to write their own "real CHKDSK".
Setting the Dirty bit, and letting Windows do it, is perfectly
acceptable.

The dirty bit cannot be cleared by the user. The details
of the dirty bit are intentionally hidden, so users will
not try to defeat the dirty bit. As in the Technet article above,
the correct invocation and running of CHKDSK is supposed
to result in the Dirty bit being cleared at the end of the
run.

It sounds like you're in a "CHKDSK loop", where the OS knows
the partition needs to be repaired, and the repair operation
is not completely successful. For example, if CHKDSK were to
crash while running, then the end of the sequence would not
clear Dirty. Fixing a CHKDSK loop isn't always easy.
Connecting the disk causing this, to another desktop PC,
and running CHKDSK on it as if it was a "data disk",
is one way to have some interactive feedback about the
process. While you can use CHKDSK done at boot time, then
look in Event Viewer for a Winlogon entry containing the
CHKDSK log output, that's a pretty silly way to do things.
Most people (me included) get lost inside the Event Viewer - like
many syslog-type implementations, there is an assumption
users like to be buried in last years error list. When all people
really want to see is "what broke in the last ten minutes".

Paul

"Micky" wrote in message
...
[Default] On Thu, 22 Oct 2015 17:17:46 -0400, in
microsoft.public.windowsxp.general "Bill Cunningham"
wrote:


"Paul" wrote in message
...

Maybe it took a small corruption in the file system,
followed by a CHKDSK you'd run, to cause it to disappear
when the corruption was corrected ?

Yes fat32 does that everytime the computer restarts. chkdsk.

It does? Seems to me it only does that when a flag tells it that
there has been an error, mostly following a crash.

If you decide to skip chkdsk, that's not a complete rebuff and it
keeps asking you every time.

I did indeed do that several times. Would that not be a good idea do
your think?

But once you say yes and let it run, it
won't run again unless something goes wrong and it knows about it.

Bill

[Default] On Fri, 23 Oct 2015 13:41:53 -0400, in
microsoft.public.windowsxp.general "Bill Cunningham"
wrote:


"Micky" wrote in message
.. .
[Default] On Thu, 22 Oct 2015 17:17:46 -0400, in
microsoft.public.windowsxp.general "Bill Cunningham"
wrote:


"Paul" wrote in message
...

Maybe it took a small corruption in the file system,
followed by a CHKDSK you'd run, to cause it to disappear
when the corruption was corrected ?

Yes fat32 does that everytime the computer restarts. chkdsk.

It does? Seems to me it only does that when a flag tells it that
there has been an error, mostly following a crash.

If you decide to skip chkdsk, that's not a complete rebuff and it
keeps asking you every time.

I did indeed do that several times. Would that not be a good idea do
your think?

Well, I skipped it when I was just about certain there were no new
errors to correct. Perhaps it was when the windows crash took place
before any of my own data files were open, and when windows wasn't
doing much.

So I skipped the chkdsk, but then it suggested it again the next two
times and I realized that it wasn't going to take No for an answer,
unless I said it every time forever. So unless I was really in a
hurry and I was certain there were no errors to correct, there's no
point in saying No. I let it run and then it doesn't nuzhie me
anymore to run the next times I start windows, unless there's another
crash.

So I unless I have to find a phone number and it's 5 minutes before
the store closes, I let it run.

If I wasn't sure there were no errors, but I was in the big hurry to
look up the phone number, that's never happened, but I guess it would
be good to look up the phone number and restart it asap so it would
run chkdsk as soon as possible. Until last month, chkdsk either
repaired all the files adequately** or the files themselves weren't
important, like temp files.

And that's my recommendation.

It displays errors as it finds them, and you can see what files have
the errors and what sort of errors they are.

And I thought the full report was available in Event Viewer, but when
I needed it, I couldn't find it there.

**Some things afaict it always gets right, like correcting length
listed to match the real length -- is that what it does?

With overlapping files, two index entries that point to the starting
addresses and lengths such that the file areas overlap, it makes
another copy of the area and points one of the index entries to the
new copy. That should always work iiuc.

But there must be problems it can't repair. Well, I had that a month
ago. Worthy of another thread.

AFAIK, if chkdsk can't repair the file, it wasn't usable anyhow. At
least I hope that's the case!!




But once you say yes and let it run, it
won't run again unless something goes wrong and it knows about it.

Bill

Paul wrote:

Bill Cunningham wrote:
"Paul" wrote in message
...

Maybe it took a small corruption in the file system,
followed by a CHKDSK you'd run, to cause it to disappear
when the corruption was corrected ?

Yes fat32 does that everytime the computer restarts. chkdsk.

Bill



https://technet.microsoft.com/en-us/.../bb490641.aspx

fsutil query dirty C:

*******

There are several things that can happen:

1) Requesting CHKDSK of the OS partition, causes the check
to be queued to a later time.

BootExecute registry key
Autochk or similar

Multiple lines of text can be contained in the BootExecute key.
Since BootExecute is executed early, some simple kinds of malware
used to add a line to it.

2) A crash causes the Dirty bit to be set. The Dirty bit
is detected by checking at startup. There is a Dirty bit
per partition.

3) The user uses FSUTIL to set the dirty bit, similar to (2).
This is sometimes done on purpose by stuff. For example, mounting
a partition from Linux, Linux can set the Dirty bit, as a "signal"
to Windows to clean up a potential mess. This is because the
Linux people don't want to have to write their own "real CHKDSK".
Setting the Dirty bit, and letting Windows do it, is perfectly
acceptable.

The dirty bit cannot be cleared by the user. The details
of the dirty bit are intentionally hidden, so users will
not try to defeat the dirty bit. As in the Technet article above,
the correct invocation and running of CHKDSK is supposed
to result in the Dirty bit being cleared at the end of the
run.

It sounds like you're in a "CHKDSK loop", where the OS knows
the partition needs to be repaired, and the repair operation
is not completely successful. For example, if CHKDSK were to
crash while running, then the end of the sequence would not
clear Dirty. Fixing a CHKDSK loop isn't always easy.
Connecting the disk causing this, to another desktop PC,
and running CHKDSK on it as if it was a "data disk",
is one way to have some interactive feedback about the
process. While you can use CHKDSK done at boot time, then
look in Event Viewer for a Winlogon entry containing the
CHKDSK log output, that's a pretty silly way to do things.
Most people (me included) get lost inside the Event Viewer - like
many syslog-type implementations, there is an assumption
users like to be buried in last years error list. When all people
really want to see is "what broke in the last ten minutes".

Paul
Paul,

I think you mean:

fsutil dirty query C:


JT

JT wrote:
Paul wrote:

Bill Cunningham wrote:
"Paul" wrote in message
...
Maybe it took a small corruption in the file system,
followed by a CHKDSK you'd run, to cause it to disappear
when the corruption was corrected ?
Yes fat32 does that everytime the computer restarts. chkdsk.

Bill


https://technet.microsoft.com/en-us/.../bb490641.aspx

fsutil query dirty C:

*******

There are several things that can happen:

1) Requesting CHKDSK of the OS partition, causes the check
to be queued to a later time.

BootExecute registry key
Autochk or similar

Multiple lines of text can be contained in the BootExecute key.
Since BootExecute is executed early, some simple kinds of malware
used to add a line to it.

2) A crash causes the Dirty bit to be set. The Dirty bit
is detected by checking at startup. There is a Dirty bit
per partition.

3) The user uses FSUTIL to set the dirty bit, similar to (2).
This is sometimes done on purpose by stuff. For example, mounting
a partition from Linux, Linux can set the Dirty bit, as a "signal"
to Windows to clean up a potential mess. This is because the
Linux people don't want to have to write their own "real CHKDSK".
Setting the Dirty bit, and letting Windows do it, is perfectly
acceptable.

The dirty bit cannot be cleared by the user. The details
of the dirty bit are intentionally hidden, so users will
not try to defeat the dirty bit. As in the Technet article above,
the correct invocation and running of CHKDSK is supposed
to result in the Dirty bit being cleared at the end of the
run.

It sounds like you're in a "CHKDSK loop", where the OS knows
the partition needs to be repaired, and the repair operation
is not completely successful. For example, if CHKDSK were to
crash while running, then the end of the sequence would not
clear Dirty. Fixing a CHKDSK loop isn't always easy.
Connecting the disk causing this, to another desktop PC,
and running CHKDSK on it as if it was a "data disk",
is one way to have some interactive feedback about the
process. While you can use CHKDSK done at boot time, then
look in Event Viewer for a Winlogon entry containing the
CHKDSK log output, that's a pretty silly way to do things.
Most people (me included) get lost inside the Event Viewer - like
many syslog-type implementations, there is an assumption
users like to be buried in last years error list. When all people
really want to see is "what broke in the last ten minutes".

Paul
Paul,

I think you mean:

fsutil dirty query C:


JT

Apparently manual copy and paste is not
one of my strong suits :-(

Paul

In message , Paul
writes:
[]
process. While you can use CHKDSK done at boot time, then
look in Event Viewer for a Winlogon entry containing the
CHKDSK log output, that's a pretty silly way to do things.
Most people (me included) get lost inside the Event Viewer - like

(I certainly do!)

many syslog-type implementations, there is an assumption
users like to be buried in last years error list. When all people
really want to see is "what broke in the last ten minutes".

Paul

Cannot the log be cleared (or, perhaps better, archived - renamed or
similar)?
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

I quite like being cosy and complacent, I'm not doing any harm. I like to
watch talented people make cakes. So there. - Alison Graham, RT 19-25 October
2013

J. P. Gilliver (John) wrote:
In message , Paul writes:
[]
process. While you can use CHKDSK done at boot time, then
look in Event Viewer for a Winlogon entry containing the
CHKDSK log output, that's a pretty silly way to do things.
Most people (me included) get lost inside the Event Viewer - like

(I certainly do!)

many syslog-type implementations, there is an assumption
users like to be buried in last years error list. When all people
really want to see is "what broke in the last ten minutes".

Paul

Cannot the log be cleared (or, perhaps better, archived - renamed or
similar)?

A recipe was posted a while back.
This is what I have in my notes file.

(Event Viewer cleaning recipe, one-liner for powershell)
http://jpwaldin.com/blog/?p=166

(To be run in an Administrator powershell.exe window)

wevtutil el | Foreach-Object {wevtutil cl "$_"}

The thing is, there are a whole bunch of separate
things that need to be cleared, so you need either
a big discrete list of the items, or as in that
example, loop through the entire list and
hammer everything. It's not like there is a
master control that just resets it.

And naturally the next question would be whether that
works in WinXP, and I haven't tried it out here so don't know.

Paul