Replacement option(s) for chkdsk

[fincoder]

Only if you keep the drive connected

???
We're discussing disconnecting the drive. Using Safely Remove on a File History drive is the only way to know it's not being written to, apart from going to the File History panel to check the status and hoping it doesn't start again just as you're yanking out the drive File History can be set to backup every 10 mins, other backup software does it in real time!

I would presume that they should not apply to any technician here

I specifically mentioned advice to customers. Telling them to check if they have File History or other backup software active, or a minimised window with a file open, is much more difficult then simply telling them to safely remove (or shutdown). I find that users, once told, are happy to do it.

Techs might be reasonably sure there's no background process writing to the drive and their behaviour doesn't concern me.

One can think of many situations where "just yanking the plug" would be a horrible idea, but all of them involve active write activity to the drive at the moment the plug was pulled

Situations like File History or other automatic backup software.

 

[britechguy]

We're discussing disconnecting the drive.

And we still were. You were referring to possible issues from background processes potentially writing to a drive. I stated, and state again, I explicitly do not allow that sort of background process to run. The only time a drive used for something like File History or any other backup process should be attached is when a backup is being taken, or a restore being performed. In this day and age to do otherwise, with the danger of ransomware, is not advised.

I, you, and anyone can tell, clearly when a run of a triggered File History or other backup is complete. You can safely remove the drive when nothing is actively writing to it.

If you won't concede that it is a simple matter to tell whether disk activity is occurring for an external drive then we have nothing to discuss. I haven't accidentally pulled a drive that's being actively used ever.

 

[labtech]

The quick physical removal is ok if the drives are formatted with FAT based file systems. All other file systems are journal based, so if things in the journal did not get to write fully to the drive and it gets suddenly disconnected/unplugged, then there will be file system inconsistencies. CHKDSK will most certainly initiate.

 

[GTP]

And I have the feeling, and "stupid play experience," to suggest you wouldn't. Generally if something gets screwed up it is the file under active write activity, nothing else.

I have never seen an entire drive be completely unreadable, or anything close to it, even when pulled in the middle of furious write activity.

This is where our experiences differ to the extreme. I have lost entire drives by pulling them during "furious write activity."
It is possible to recover the drive on many occassions with chkdsk, but also on many occasions it results in a corrupted and unreadable drive.
I've learned a hard lesson in having patience not to do it again.

 

[NETWizz]

@NETWizz Self Healing NTFS was added with Windows 7 and Server 2008. That is literally the feature name... Google it. Basically, NTFS runs chkdsk for you automatically when it detects issues. The OS has scheduled tasks that also run chkdsk periodically built in.

So one should never have to run it themselves, and if they do... the drive is dead because you're in that 2nd category you've listed. If you see errors when running chkdsk bad things are happening to your data due to storage issues.

@britechguy I haven't had a USB storage device suffer data-loss on disconnect without the USB storage device itself FAILING at that same time in over a decade. The only time I use the eject button in Windows is when I'm working with magnetic external storage, to make sure it's done writing. USB storage is done writing when the file copy progress window goes away. You can still screw up files if you unplug during a file operation obviously, but in most cases those operations are obvious and people just don't do that. So yeah, I too don't bother with the eject button for USB keys... waste of time. Just unplug it when the writes are done.

Automatically running chkdsk hardly makes it self healing. It's a bandaid.

A true self-healing filesystem never finds itself inconsistent needing a tool run. Something like ReFS. It literally displays this.

 

[fincoder]

I explicitly do not allow that sort of background process to run.

I'm talking about advice to customers, not our own computers.

I, you, and anyone can tell, clearly when a run of a triggered File History or other backup is complete.

I disagree, it's not necessarily easy to tell when a backup is complete, or whether it's about to start again. File History has no indication unless you go into the control panel applet and look at the status, then calculate from the last run time whether it's about to automatically start again. The scheduled-backup feature of File History can't actually be turned off, even if you plan to manually attach & detach the drive. It has a convenient Run Now feature to kick it off manually which works well, but if the schedule is still set to 'every 10 minutes' then determining that it's not currently writing to the drive is not as easy as you're making out. And checking the control panel applet before yanking is not easier than clicking Safely Remove.

OK, so background backup processes aside, why does Safely Remove quite often reject the request? Obviously some part of the OS or filesystem thinks a file is being accessed.

 

[fincoder]

The quick physical removal is ok if the drives are formatted with FAT based file systems.

Does this include NTFS?

 

[britechguy]

I'm talking about advice to customers, not our own computers.

I disagree, it's not necessarily easy to tell when a backup is complete, or whether it's about to start again. File History has no indication unless you go into the control panel applet and look at the status, then calculate from the last run time whether it's about to automatically start again. The scheduled-backup feature of File History can't actually be turned off, even if you plan to manually attach & detach the drive. It has a convenient Run Now feature to kick it off manually which works well, but if the schedule is still set to 'every 10 minutes' then determining that it's not currently writing to the drive is not as easy as you're making out. And checking the control panel applet before yanking is not easier than clicking Safely Remove.

OK, so background backup processes aside, why does Safely Remove quite often reject the request? Obviously some part of the OS or filesystem thinks a file is being accessed.

My advice to my customers is indistinguishable from my advice to myself. I don't get why that's difficult. I don't find it at all difficult to know when a drive is in active use. And, I keep saying, over and over, the only way I use File History is with manual (Run Now) triggering. I don't use any backup utility otherwise now (NO SCHEDULING for all practical intents and purposes, and never at an interval like 10 minutes. Mine is set to "daily" which doesn't leave much room for error in knowing when File History has said it's done, it's done for many hours). There was a time when that was not the case, but now, with ransomware, external backup drives are not to be connected except to take a backup or perform a recovery. I don't know how else to make that any clearer.

Ignoring backups, I have gotten "file being accessed" warnings for files I've opened in things like MS-Word, or a PDF viewer, that I absolutely know are not open at that moment, anywhere. Spurious warnings exist.

Let's just agree to disagree. Neither one of us is going to convince the other, and I have already stated that if you feel you must use eject, then you should. Anyone who wants to safely eject should do so. I don't want to, as I've never had any need, so I don't.

Our experiences and viewpoints are divergent. That's OK.

 

[labtech]

Does this include NTFS?

No, as NTFS is NT File System, which is a journaling file system.

NTFS - Wikipedia

en.wikipedia.org

 

[fincoder]

Yes I assumed you were excluding NTFS but wanted to clarify. So do you advocate yanking flash drives (usually FAT32) but not portable HDDs (usually NTFS)?

 

[NETWizz]

Actually, what matters most with removing flash drives is the policy for removal more than the filesystem. Sure you don't want a corrupt filesystem, but really in practice what happens is corrupt files that are partially written and a mostly okay filesystem.

 

[britechguy]

Actually, what matters most with removing flash drives is the policy for removal more than the filesystem.

And, just to repeat, the Quick Removal policy has been the default policy for many years now. Many.

This particular comment on hardware.slashdot.com could have been my own. It was written in response to the "major announcement" by Microsoft that the removal policy had been changed to Quick Removal in Windows 10 Version 1809 when it had been Quick Removal for many years before that. Those who still have Windows 7 machines or XP machines can easily check this out themselves. It opens with:

"EVERY SINGLE WINDOWS since XP defaults to "Quick Removal" for ALL removable drives, including every iteration of Windows 10. I have yet to see a single computer running XP, Vista, 7, 8, 8.1, or any build of 10 where I plug in an SD card, USB flash drive, or USB hard drive that did NOT automatically default to "Quick Removal." I have ALWAYS, as in 100% of cases, had to manually switch the performance setting through Device Manager. Anyone who says that the default policy is different is flying directly in the face of every single computer I've ever plugged a USB or memory card storage medium into over the past 17-18 years, and that's literally thousands of machines."

Again, to be clear, if you want to eject, then do so. But that does not change the fact that the Quick Removal policy has been the default for removable drives of every ilk for a very, very, very long time now. As a result, many of us do consider using eject to be entirely optional when it's clear there is no drive activity occurring at the time we're pulling the drive. Since the vast majority of drives have some sort of indicator of R/W activity, that's not hard to determine.

 

[labtech]

Yes I assumed you were excluding NTFS but wanted to clarify. So do you advocate yanking flash drives (usually FAT32) but not portable HDDs (usually NTFS)?

It does not matter what USB device it is. Anything USB is technically "portable", right?
So, it is about the file system. FATs are ok, anything else not really.

Here is an example I am sure you have experienced with good healthy drives, say NTFS, HFS+ and so on:
When asking to safely remove the device, it gives a prompt saying "Not ready... still in use bla bla, close application using it bla bla".
Likely, the journaling entries have not finished being permanently written to the drive, hence the prompt.
If waiting for a while, the journaling will finish and the drive could be removed safely.
Now, that is what is to expect in ideal good scenario.

Anything else, with weird issues, corresponding applications open, damaged drives, corrupt file systems and so on, then it could be a variety of issues, often without being able to find the culprit.

 

[britechguy]

So, it is about the file system. FATs are ok, anything else not really.

All I can say is that this does not comport with my experience. I have "just pulled" USB backup drives that are NTFS formatted for years and years without incident after checking that no active RW activity is occurring.

That policy is about how windows handles things, and under quick removal, regardless of file system, RW is supposed to be done on demand, not buffered waiting for an eject. And that's precisely how I've observed it to behave.

I've also had plenty of exFAT formatted flash drives I "just pull," too.

 

[labtech]

Right, exFAT is a FAT file system, no journaling.
Saving entries from the journal is a write operation, as everything is read or write.
So, if no activity takes place, yanking away is no problem.
Cheers!

 

[fincoder]

It does not matter what USB device it is. Anything USB is technically "portable", right?
So, it is about the file system.

Yep I get that, but flash drive are almost always FAT, portable HDDs are almost always NTFS.
My comments are coming from the point of view of advice to end users.

When asking to safely remove the device, it gives a prompt saying "Not ready... still in use bla bla, close application using it bla bla".
Likely, the journaling entries have not finished being permanently written to the drive, hence the prompt.
If waiting for a while, the journaling will finish and the drive could be removed safely.

Yep. I've brought up the scenario where eject is rejected several times in this thread because I was hoping for an explanation. Your explanation makes sense.

Microsoft's apparent advice that due to the Quick Removal safely remove isn't necessary, seems at odds with the fact their OS often rejects the eject request. It wouldn't be the first time Microsoft has botched their communications to users.

 

[Rigo]

Is it just me or does Windows routinely have a problem letting go of USB external drives? I can almost always eject USB flash media from within Windows but rarely will Windows let go of an external USB drive. I either have to repeatedly ask for the USB drive to be disconnected or shut down the machine before unplugging the drive.

I've found restarting Windows Explorer once or twice in Taskmgr will make it give up on the drive so it can be ejected.
A little quicker than full restart which sometimes still doesn't release the drive from whatever is holding it

 

[fincoder]

A little quicker than full restart which sometimes still doesn't release the drive from whatever is holding it

Once shutdown the drive can be yanked out safely. No need to boot up to safely remove.

 

[britechguy]

A little quicker than full restart which sometimes still doesn't release the drive from whatever is holding it

Which tells you, instantly, that it's a spurious message. Nothing holds a drive between restarts.