Code Change Request

# 27079

Back to Code Changes

Christopher
Technical Support
StableBit CloudDrive
1.0.0.463
Windows Server 2012 R2
Public
Alex

* [D] [Issue #27079] Added a new option (CloudFsDisk_IsQuickRemoval) that controls whether removable cloud drives default to the "Quick removal" policy by default.
This does not apply to drives using the Local Disk provider, those drives always default to "Better performance". The Removal policy can be 
changed at any time, on a per-drive basis, by opening Device Manager and going into the cloud drive's disk properties. This is True by default.
* [D] [Issue #27079] Added a new option (CloudFsDisk_IsDriveRemovable) that controls whether cloud drives advertise themselves as removable drives to PnP. Removable 
drives expose the "Removable policy" tab in the drive's property window (in Device Manager). This is True by default.
Public
Alex

In NTFS, the data is not safeguarded against corruption in case of a power failure, but the volume's metadata is. So if you're copying a file to the drive and power loss occurs, the data in that file could be gone, the file could be gone, etc...

Here's a good write up on this, as it pertains to USB drives (but applies to our cloud drives too):
https://blogs.msdn.microsoft.com/oldnewthing/20130101-00/?p=5673

But, I've made some changes to the driver code to enable the "Quick removal" policy which should minimize the chances of data loss occurring due to a surprise removal. This was actually surprisingly difficult, but I'm just finalizing and testing those changes now.
Public
Alex

Funny thing, I was just reading about this in Windows Internals the other day:

NTFS Recovery Support

NTFS recovery support ensures that if a power failure or a system failure occurs, no file system operations (transactions) will be left incomplete and the structure of the disk volume will remain intact without the need to run a disk repair utility. The NTFS Chkdsk utility is used to repair catastrophic disk corruption caused by I/O errors (bad disk sectors, electrical anomalies, or disk failures, for example) or software bugs. But with the NTFS recovery capabilities in place, Chkdsk is rarely needed.

As mentioned earlier (in the section Recoverability), NTFS uses a transaction-processing scheme to implement recoverability. This strategy ensures a full disk recovery that is also extremely fast (on the order of seconds) for even the largest disks. NTFS limits its recovery procedures to file system data to ensure that at the very least the user will never lose a volume because of a corrupted file system; however, unless an application takes specific action (such as flushing cached files to disk), NTFS’s recovery support doesn’t guarantee user data to be fully updated if a crash occurs. This is the job of transactional NTFS (TxF).

...

File system recovery begins automatically the first time the volume is used after the system is rebooted. NTFS checks whether the transactions that were recorded in the log file before the crash were applied to the volume, and if they weren’t, it redoes them. NTFS also guarantees that transactions not completely logged before the crash are undone so that they don’t appear on the volume.

----

Based on that, we should be in terms of how we're unmounting. NTFS guarantees that the metadata will not be corrupt, but no guarantees are made about the data being copied to the drive (or updated on the drive) during the unmount. Existing data on the drive should not be affected.

ReFS may be able to deal better with this? I can't find any into on ReFS in Windows Internals (7th edition is coming soon).