Christopher (Drashna)

It's in the same spot. We don't have any plans on adding this. Especially as it would require a complete redesign of the software and UI.

Does this persist if you use the latest beta? https://dl.covecube.com/ScannerWindows/beta/download/StableBit.Scanner_2.6.14.4112_BETA.exe

Using both the older and newer version of teracopy on a very large and full pool, it definitely SHOULD NOT be locking up the machine. As shane mentions, this may indicate a problem drive (as that could definitely cause this behavior). Also, it might be worth running a memory test on the system, as well.

the balancing shouldn't really matter much in this case. Though, it's odd about the destiny files, unless the drive in question was pretty full (if it gets too full, the rules may allow data to be placed on the other drives)

The process is more than just moving the data, so it may be hitting the same percentage due to the process and where it's out, and how much data needs to be moved. Eg, it should be fine.

If you're having issues, could you open a ticket at https://stablebit.com/contact

The simplest option would be to create the second drive and move things over. But I believe you should be able to create a new iDrive connection, using the new endpoint and bucket ID, and then mount it with that new connection. (it may be worth creating a small test drive first to verify the process)

well, I'm sorry to hear about the hardware failure, but I'm glad to hear that StableBit DrivePool has made things dead simple!

The reset is mostly to ensure that remeasuring occurs. Triggering just the remeasuring should be fine, though. And the service stop is to prevent it from running balancing or duplication tasks, and to prevent it from remeasuring while moving data into the pool folder structure. Eg, we want to make sure it's as un-interrupted as possible. So, no, you still want to stop the service, as there are other tasks that can be triggered that you don't have as much control over. And since all of these tasks are controlled by the service...... > 2/ snaparaid : is it concerned by the fileid problem that could lead to potential file corruption, as long as no application like onedrive or filesyncing app is not use? The biggest issue is that many apps incorrectly expect that File IDs never change. Which is NOT what the NTFS specifications state. File IDs can and do change, and if you need the ID to never change, Object IDs should be used. And the misunderstand and misuse of these behaviors has caused issues. SnapRAID in no way deals with this problem, as you should be targeting the underlying disks, and NOT the pool.

I'm glad to hear it!

DO NOT TOUCH THE UNINITIALIZED DISKS. Reconnecting the enclosure may be a good idea. But I would highly recommend running data recovery on them (such as test disk, recuva, etc), something that can recover the partition tables. Any other action on the drives may/will overwrite the partition tables and make things that much more difficult to recover.

If you haven't already, enable and open the advanced settings in StableBit Scanner. In the advanced settings, find the "Smart" section and check the "IgnoreChecksum" option. http://wiki.covecube.com/StableBit_Scanner_Advanced_Settings This will most likely fix the issue with the drives not showing the SMART data.

I've been buying manufacturer recertified drives for a while now. Sounds like that isn't going to change, but is already getting more expensive. Aside from that, there really isn't a solution. Buy what you can, when you can. Double check the manufacturer's warranty period (and expect those to drop, as well).

tl;dr: Reset the settings in StableBit DrivePool: https://wiki.covecube.com/StableBit_DrivePool_Q2299585B The drives shouldn't appear as both pooled and unpooled. Also, pooled drives shouldn't show up as (just) unpooled drives. And in both cases, there may be some corruption of the local pool config (for the service). While this isn't critical (eg, it shouldn't break anything), it's not supposed to happen. Rebooting the system may fix this, as may restarting the service, as it should reload the information. However, this doesn't always fix things, and in this case resetting the settings should fix this (as it clears out the locally saved settings and rebuilds the data from scratch, from the pooled drives) If this keeps happening, though, open a ticket at https://stablebit.com/Contact and let us know.

They posted a ticket too, but since the information is super useful, I wanted to post it here, too: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry This covers the two main methods to deal with path length issues (which I suspect is the root issue here). Namely, the registry hack for Win32's long path support (which I've personally found is either finicky or outright doesn't work). Or using full UNC paths (eg, adding "\\?\" to the beginning of the path), which I've found works much better. This format is supported by .NET programs, full. So things like Emby, and Jellyfin should work just fine with (Plex should too).n