Commandline copy poltergeists.

[fleggett1]

What in the sam hell does this mean when trying to do a cmd-based copy using a filename mask?

"The system cannot find the file specified."

This is what I get when trying to do a "copy * [destination]" in a few directories in Windows 11 on my one (and only) Drivepool pool.  I can copy the files if I don't use a wildcard, but I've never seen this sort of error and it's got me really, REALLY spooked.  All of the files just have the "A" attribute and there aren't any other hidden or system files in these directories.

xcopy under cmd works.  And the internal copy command in Powershell works, so it's something endemic to vanilla cmd.

I'm confuzzled!

[JazzMan]

Is the pool healthy?  Is it using duplication?  does chkdsk'ing the individual drives in the pool show any errors?  Are there any hidden files you're trying to copy?  Are there any extremely long paths/filenames or unicode characters involved?

I get very sporadic errors like this if duplicated files are mismatched or before some error that a chkdsk /f fixes.

I don't know exactly why copy would behave differently than xcopy or powershell, but I'm sure the code is different, so edge cases are being handled differently.

 

[fleggett1]

The pool is healthy and I'm not using any duplication.  I haven't run chkdsk, so that's something to try.  No hidden files, no long paths, and no weird unicode stuff involved.  I am running the pool off of a Sabrent 10-bay enclosure, but I don't see why that would be a factor.

I'll run chkdsk when I can get to the pool again.  I just want some stability in my life at this point, as I built a new machine with a screaming Ryzen 9 cpu to replace my old Norco and have had all sorts of problems, with this being just another one.  No crashes, just strange stuff that isn't really DP or Scanner related (most of it involving the igpu/HDMI).

[JazzMan]

5 hours ago, fleggett1 said:

"copy * [destination]"

The pool is healthy and I'm not using any duplication.

The only other two things I can think of are not correctly putting quotes around [destination] if it has spaces, and some issue with the ACL (permissions) getting borked on some file(s) in the source.  

If you are in CMD and type your;

copy * [destination]

that gives the error, what then happens if you do a;

dir [destination]

Also, what happens if you do;

copy *.* [destination]

instead of just the single asterisk?

Another thing you could try is mounting each drive in the pool as a separate drive letter or mountpoint and going through them one at a time with the copy command to see which disk "behind the scenes" is giving the error.

I don't think it's a disk corruption or DP issue though from what you've said, especially if there isn't duplication.  I think it's something about the way you are using the copy command.

[fleggett1]

I actually tried several variations of the copy command, like *.* and *?.?* and none of them worked.  However, for some cosmically unknown reason, now it's working under cmd with no elevation.  I'm 100% serious.  I can only surmise that an application had gotten ahold of the directory at the same time I was attempting the copy command and had temporarily made it exclusive, as I haven't rebooted.  However, even if that was the case, it doesn't explain why xcopy and Powershell's copy worked.

It gets even better, though.  I did an admin-level chkdsk in both cmd and powershell on the pool and got this in return:

The type of the file system is RAW.
CHKDSK is not available for RAW drives.

I don't know what the frak is going on.  The pool seems to be working just fine and disk management reports that each drive is NTFS'd, but chkdsk thinks the pool isn't formatted?  Is the Sabrent enclosure futzing with things in ways DP and Windows can't understand?  Do I need to bring in a witch doctor?

I suppose another thing to consider is that the pool wasn't created in my current Windows 11 environment, but in my previous Windows 10 one.  I'm beginning to fear that I'm gonna have to start things over from scratch, but that's probably going to necessitate getting a second enclosure since this one is full and I just don't have that kind of cash lying around right now.

[Shane]

DrivePool returning RAW for pools to chkdsk is normal behaviour (because a pool is not itself a physical drive with sectors to check, even if it's made up from them).

It may just be that your guess of another application grabbing the directory at the time is correct, and that xcopy and powershell copy just have better handling of such situations (which I can believe).

[JazzMan]

1 hour ago, fleggett1 said:

The pool seems to be working just fine and disk management reports that each drive is NTFS'd, but chkdsk thinks the pool isn't formatted? 

The pool is a collection of NTFS drives, but the file system the pool driver presents to windows isn't 100% NTFS.  It's close, but there a few things native NTFS can do that the driver can't.  Even if it says "NTFS" if you do a "Properties" on the pool's drive letter, behind the scenes it is technically "CoveFS" or something.  This is why chkdsk isn't working.  That isn't a problem.  You can't CHKDSK the pool.  The driver doesn't support that.  You would CHKDSK the drives in the pool individually.

[fleggett1]

Oh.  That's...interesting.  Well, at least that's something I can rule out when it comes to pool mysteries, as I thought for sure I had a huge problem after the chkdsk thing.

I suppose I could chkdsk the individual disks myself manually, but I expect Scanner does all that periodically and then some (at least, I hope so).

[JazzMan]

4 hours ago, fleggett1 said:

I suppose I could chkdsk the individual disks myself manually, but I expect Scanner does all that periodically and then some (at least, I hope so).

I can be corrected, but I don't think Scanner performs the same functions as Chkdsk.  My understanding is Scanner is monitoring SMART data and exercising the drives to prevent bit rot.  Chkdsk is intended to ensure that the various metadata and such of a file system (NTFS in this case) are all complete and consistent.  The former is more of a hardware level operation, the latter more of an OS level operation.  These days, chkdsk errors are more the result of programs crashing while writing to the disk than of issues with the physical media.

It sounds lie you got past the error you posted about, although your post seems to imply you've been having other issues or frustrations with your setup.

My two cents;

• (Assuming you don't have drive letters for each of the 10 drives) Create a folder on your C: drive and in it create NTFS mount points for each of the 10 individual drives.  That way you can then easily see the contents of an individual drive or chkdsk the mount point.
• Create a *.bat script to chkdsk the 10 drives.
• Re-consider the DAS solution, especially before buying a second enclosure

I don't know your use case, but having a JBOD enclosure hanging off a computer by USB/USBC/eSATA is always going to be less performant than having drives connected to internal SATA ports, and is also going to be more prone to drives dropping out under any sort of load.  Without duplication, and with only one enclosure, you have also not mentioned what your backup strategy is.   If you are tech savvy enough, I'd really recommend building a separate NAS computer, running DP on that, and serving up the files you need over the LAN.  I've used Norco ITX-S8 cases in the past, but they're out of business now.  It looks like Jonsbro makes cases with backplanes for NAS builds.  Mostly they max out at 8x usually.  I'm not sure if anyone makes 10x ones.  You might have to get some larger drives or build in a non-backplane (non hot-swap) case for that.

 

[Shane]

20 hours ago, JazzMan said:

My understanding is Scanner is monitoring SMART data and exercising the drives to prevent bit rot.

Scanner does monitor (e.g. every minute or so, can be configured) SMART data and also regularly (e.g. monthly, depends on your setup choices) scans both the file system and every sector on your drives to check that they are readable, and can attempt repairs.

The scanning as a (nice) side-effect can also prevent some bit rot, as the act of scanning ensures the drive will be regularly fully powered up and that the drive's own detection/correction features will (or at least should) automatically examine/repair/reallocate cells/sectors in the background as Scanner reads them. Note that SSDs are much more susceptible to charge decay than HDDs, as the former relies on a much faster but less stable storage method; it can vary widely by the type of SSD but the  general takeaway is that a SSD/HDD that's been sitting unused for X months/years respectively might not keep your data intact (the bigger the X, the smaller the trust).

Anyway, aside from the problem mentioned with SSDs above, drive-based bit rot (as opposed to other sources and causes, e.g. due to bad RAM, EM spikes, faulty controllers, using non-ECC memory in a system that doesn't get cold-booted regularly, etc) is by itself quite rare, but it is yet another reason to keep backups.

TLDRs: if you keep necessary data on a SSD, I suggest keeping it powered continuously or at least regularly. Regularly scan your SSDs and HDDs. Keep backups. If you're not using an ECC setup, consider disabling "Fast Start" in Windows 10/11 and restarting your PC occasionally (e.g. once a month) if you're not already doing so.