If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#16
|
|||
|
|||
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. |
Ads |
#17
|
|||
|
|||
late experiences with fat32
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 |
#18
|
|||
|
|||
late experiences with fat32
[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. |
#19
|
|||
|
|||
late experiences with fat32
"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 |
#20
|
|||
|
|||
late experiences with fat32
"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 |
#21
|
|||
|
|||
late experiences with fat32
[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 |
#22
|
|||
|
|||
late experiences with fat32
[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. |
#23
|
|||
|
|||
late experiences with fat32
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 |
#24
|
|||
|
|||
late experiences with fat32
"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 |
#25
|
|||
|
|||
late experiences with fat32
[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 |
#26
|
|||
|
|||
late experiences with fat32
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 |
#27
|
|||
|
|||
late experiences with fat32
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 |
#28
|
|||
|
|||
late experiences with fat32
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 |
#29
|
|||
|
|||
late experiences with fat32
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 |
|
Thread Tools | |
Display Modes | |
|
|