Is he right about scandisk

[Cerb]

So checkdisk/scandisk can alter the video?, but only if you set it to repair?, and by altering i mean totally corrupting not changing the quality or adding slight glitches to the film.

someone please reply.

*sigh* OK, lessee if I can break this down.

Your file needs to appear to you, and any programs, as a specific ordered string of bytes, with a specific name, and other properties.

So, you might have MyRec.ts, a 500MB OTA capture, stored as C:\Users\Me\My Videos\MyRec.ts.

How does it know there even is a folder called Users, Users\Me, much less Users\Me|My Videos? How does it know there's a file there? How does it know what it's called? How does it know when it was made? How does it know when it was last written to? How does it know who owns it? And so on...

The file system handles that. The file system, however, is little more than ordered strings of bytes, too, just like files are. To the hard drive itself, there's no difference.

Now, on top of that, your file may be made up of many parts, scattered about the system (the more free space you have, the less likely this is). When reading the file, the file system driver finds a list of those parts (fragments), and stitches them together as needed.

While it's recording, it is, every so many seconds, writing out a new part of the file's data, and then also matching that by writing out an updated list of file parts (if there's plenty of space next to where it had been writing, it will update it as increasing the last fragment's size, instead). So when it records another 30s of video, it has to update not only the raw data, but also pointers to that data. Both sets of information, the file data itself, and the file system's metadata, need to be in sync. They need to match each other.

Those lists of pointers, with the file's name, logical location (IE, C:\Users\Me\etc.), and physical location(s) (800 sectors starting from sector 6500; 12000 sectors starting from sector 8999, etc.), and other info, are what make that raw data usable. Otherwise, it's just random data on the disk. Now, in normal operation, the file system does a fair bit of work to make sure they don't become incorrect in the first place (NTFS more than FAT, ReFS more than NTFS, in Windows), but dirty unmounts (use the Safely Remove Hardware icon!), dirty shutdowns (normally unpredictable, but you can use a UPS), or failing hardware (not always the HDD!) can throw a wrench in the works. Journaling file systems (such as NTFS or HPFS) are pretty good about recovering from such events, but nothing's perfect.

Chkdsk's concern is solely that those lists of information are in a proper state. If some is missing, or duplicated but different (without a way to figure out what's newer), or has impossible values (like multiple files or fragments overlapping others, or values past the end of the drive), it needs to fix it, in whatever way it can. If everything was properly written, and can be properly read, then chkdsk does nothing but set a value stating that the file system is actually OK, after reading however much it or you deemed necessary.

If chkdsk comes across errors for which there are not obvious correct values, the results are effectively unknown. I mean, with a certain set of errors in, you should always get the same repair results, but you never know what they might be, going in. So, if something isn't right, you can't necessarily know exactly what it will do. It might screw up some files, it might not. That's an unknown, if it encounters errors and goes about fixing them. But, if it goes about finding such errors, you also have no guarantee that you'd be able to correctly read the file without repairing via chkdsk, so if something is amiss with the file system, you already want to have made backups--an ounce of prevention, and all that.

If chkdsk is run without repair options, on a healthy drive, it will do nothing but spend time reading. It will then report errors it found, if any, but not fix them. Now, with a failing drive, chkdsk (or scandisk, or any fsck), being seek-heavy, will generally cause more strain on the drive, risking more data loss than trying to perform selective file recovery, or imaging, will. So, it's not a good idea to use it in that scenario, on the drive that may be failing.

The good news: drives are cheap, so backup important data. The benefits of all that complexity are that the same file copied from a Windows NTFS partition to an Apple HPFS partition to a FreeBSD ZFS partition, to an Android EXT4 partition, will, barring faulty hardware along the way, result in the same file you started with. All you lose between all that will be WIndows-specific security settings. A simple spare external drive, simple NAS, fancy NAS, custom NAS, DVD, tape, etc., all result in basically the same thing.

As long as it can have power removed from it when not in use, and you have a way to check the files themselves (look up SFV tools, and Quickpar, for practical-yet-inelegant ways to handle it, without using commercial software--not that commercial software is bad or anything, but having a process that you can make a habit with is the more important than the specific tool), you can keep them as safe as you are willing to.

 

[Robgeek]

(Changing the subject slightly, but I wanted to say this anyway).

Be very careful when unplugging external USB HDD drives.
Make sure that any files you have written to it, appear to have finished.
E.g. There may be a red flashing light, or some sign that the disk is still writing data to its disk.
They can take a while (up to a minute, maybe longer) to finish, even after it seems to have finished on your screen, because of disk buffering (Caches in windows),
Use the safely use hardware feature, BEFORE removing the USB connection (I assume you know how to do this, I'm not 100% sure if Vista does this).
Similarly, don't switch off the computer or HDD, until it has finished all writing.

If you don't do the above, then it is very possible it will cause logical errors in the stored data (NOT physical HDD damage).

When I scanned my ADATA which is a fat32 on my ntfs windows vista, using scancheck via tools > scan now. It went to 100% then the scanbox froze so I had to turn of my computer using the start menu, i tried scanning a few times same result, either turned of computer using menu or safely ejected, it always let me eject the drive even though the scanbox had frozen at 100%, is it possible another checker will be able to check for the logical errors?, can you recommend one?, I did post another thread in this forum so unsure when it may get read.

 

[Robgeek]

*sigh* OK, lessee if I can break this down.

Your file needs to appear to you, and any programs, as a specific ordered string of bytes, with a specific name, and other properties.

So, you might have MyRec.ts, a 500MB OTA capture, stored as C:\Users\Me\My Videos\MyRec.ts.

How does it know there even is a folder called Users, Users\Me, much less Users\Me|My Videos? How does it know there's a file there? How does it know what it's called? How does it know when it was made? How does it know when it was last written to? How does it know who owns it? And so on...

The file system handles that. The file system, however, is little more than ordered strings of bytes, too, just like files are. To the hard drive itself, there's no difference.

Now, on top of that, your file may be made up of many parts, scattered about the system (the more free space you have, the less likely this is). When reading the file, the file system driver finds a list of those parts (fragments), and stitches them together as needed.

While it's recording, it is, every so many seconds, writing out a new part of the file's data, and then also matching that by writing out an updated list of file parts (if there's plenty of space next to where it had been writing, it will update it as increasing the last fragment's size, instead). So when it records another 30s of video, it has to update not only the raw data, but also pointers to that data. Both sets of information, the file data itself, and the file system's metadata, need to be in sync. They need to match each other.

Those lists of pointers, with the file's name, logical location (IE, C:\Users\Me\etc.), and physical location(s) (800 sectors starting from sector 6500; 12000 sectors starting from sector 8999, etc.), and other info, are what make that raw data usable. Otherwise, it's just random data on the disk. Now, in normal operation, the file system does a fair bit of work to make sure they don't become incorrect in the first place (NTFS more than FAT, ReFS more than NTFS, in Windows), but dirty unmounts (use the Safely Remove Hardware icon!), dirty shutdowns (normally unpredictable, but you can use a UPS), or failing hardware (not always the HDD!) can throw a wrench in the works. Journaling file systems (such as NTFS or HPFS) are pretty good about recovering from such events, but nothing's perfect.

Chkdsk's concern is solely that those lists of information are in a proper state. If some is missing, or duplicated but different (without a way to figure out what's newer), or has impossible values (like multiple files or fragments overlapping others, or values past the end of the drive), it needs to fix it, in whatever way it can. If everything was properly written, and can be properly read, then chkdsk does nothing but set a value stating that the file system is actually OK, after reading however much it or you deemed necessary.

If chkdsk comes across errors for which there are not obvious correct values, the results are effectively unknown. I mean, with a certain set of errors in, you should always get the same repair results, but you never know what they might be, going in. So, if something isn't right, you can't necessarily know exactly what it will do. It might screw up some files, it might not. That's an unknown, if it encounters errors and goes about fixing them. But, if it goes about finding such errors, you also have no guarantee that you'd be able to correctly read the file without repairing via chkdsk, so if something is amiss with the file system, you already want to have made backups--an ounce of prevention, and all that.

If chkdsk is run without repair options, on a healthy drive, it will do nothing but spend time reading. It will then report errors it found, if any, but not fix them. Now, with a failing drive, chkdsk (or scandisk, or any fsck), being seek-heavy, will generally cause more strain on the drive, risking more data loss than trying to perform selective file recovery, or imaging, will. So, it's not a good idea to use it in that scenario, on the drive that may be failing.

The good news: drives are cheap, so backup important data. The benefits of all that complexity are that the same file copied from a Windows NTFS partition to an Apple HPFS partition to a FreeBSD ZFS partition, to an Android EXT4 partition, will, barring faulty hardware along the way, result in the same file you started with. All you lose between all that will be WIndows-specific security settings. A simple spare external drive, simple NAS, fancy NAS, custom NAS, DVD, tape, etc., all result in basically the same thing.

As long as it can have power removed from it when not in use, and you have a way to check the files themselves (look up SFV tools, and Quickpar, for practical-yet-inelegant ways to handle it, without using commercial software--not that commercial software is bad or anything, but having a process that you can make a habit with is the more important than the specific tool), you can keep them as safe as you are willing to.

So your saying if the file has been altered by checkdisk, it will be unreadable not have things like slight glitches in the video or clicks in the sound?(note I have'nt seen anything amiss with quality as of yet and will be backing up more in the near future) is scanning the only way to tell if a video is corrupt in any way big or small?, becoz some corrupt videos will play on some players and not on others, so can't always tell by watching them.

 

[SOFTengCOMPelec]

When I scanned my ADATA which is a fat32 on my ntfs windows vista, using scancheck via tools > scan now. It went to 100% then the scanbox froze so I had to turn of my computer using the start menu, i tried scanning a few times same result, either turned of computer using menu or safely ejected, it always let me eject the drive even though the scanbox had frozen at 100%, is it possible another checker will be able to check for the logical errors?, can you recommend one?, I did post another thread in this forum so unsure when it may get read.

I could find out what to recommend for you, but there is a very good chance that other forum posters will have a better idea of disk checking utilities that they have had very good results with.
They may also be able to talk you through the best one in your circumstances.

The big advantage of the free ones, is that you can even download them, and try them. And if you end up not liking them, just try something else.

You want good quality recommendations here, because disk checking utilities have got the capability of not doing as good a job of recovering the bad data (if present), as other, better disk utilities.

I prefer to change my disks over to NTFS, as it is usually much more robust and reliable. But I would prefer someone else to agree or disagree with that advice, before you start changing anything.
It's usually easiest to change to NTFS when the HDD drive is brand new, as then you can reformat it into NTFS, without any data to worry about backing up, or keeping safe.
Changing Fat32 to NTFS needs to be done armed with good knowledge of what you are doing, otherwise the process could actually hurt any data on the disk (in fact, it would be best to back up the data on that drive first).

 

[Mushkins]

So your saying if the file has been altered by checkdisk, it will be unreadable not have things like slight glitches in the video or clicks in the sound?(note I have'nt seen anything amiss with quality as of yet and will be backing up more in the near future) is scanning the only way to tell if a video is corrupt in any way big or small?, becoz some corrupt videos will play on some players and not on others, so can't always tell by watching them.

You're trying to simplify this situation into an absolute. If I do X, my videos will do Y. You can't, that's just not how it works. The technical details of why it doesn't work that way have been explained over a dozen times.

With any disk checking tool that attempts to repair anything it finds, there is a risk of data corruption. Moving a file from one drive to another has a risk of data corruption. Loss of power, improperly dismounting a drive before removing it, and physical hardware issues have a risk of data corruption. An unstable CPU has a risk of data corruption. Strong vibrations from a truck driving by your house has a risk of data corruption. Manipulating data in any way, shape, or form has a risk of data corruption.

In the vast majority of cases (for arguments sake, lets say 99.999% of cases) everything works fine and there is no meaningful data corruption. For those 0.001% of cases where something bad happens, thats why we have backups. We restore from backup and the world moves forward. If the backup is the one thats corrupted, we simply make a brand new backup from the original files that are still perfectly fine.
Data corruption is completely, 100%, totally unpredictable. There is no way to tell what will be corrupted (if anything) and to what extent any more than we can predict the future. The solution is to mitigate risk as much as possible, there is no magic bubble that perfectly protects your data integrity.