Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000444FlexRAID Transparent RAID[All Projects] Generalpublic2017-01-15 14:542017-11-23 13:51
Assigned ToBrahim 
PlatformWindowsOSWindows Server 2012 R2OS Version
Summary0000444: Deleted files end up in drive recycle bin
DescriptionWhen I delete a file from the pool directly on the machine it is running on (no network share), the file is moved to the (hidden) recycle bin of the corresponding drive. If I delete a file with "permanent delete" (Shift+Del) or via a network share, it shows up in the universal recycle bin (URB).

Similar behavior is observed when deleting files already in the URB: If I just use normal delete, they go to the drive's recycle bin; if I use Shift+Del, they are deleted permanently.

This is a problem since the drives' bins are not accessible when via the pool.
Steps To ReproduceDelete a file on the machine where the pool is running
Additional InformationI appended a log and did a test with three files:
/a.txt -> Regular delete => Drive's recycle bin
/b.txt -> Permanent delete => URB -> Regular delete => drive's recycle bin
/c.txt -> Permanent delete => URB -> Permanent delete => Gone

Note that this has been tested with the build.
While the files not showing up in the URB is I minor problem in my personal opinion (as one can access them if really required), it may block disk space in case of large files residing unseen in the drives' bins.
Also note that the drives' bin is not accessible when the pool is mounted (either directly through the file system or as part of the Windows recycle bin collecting all regular drives; which I suppose is intended).
TagsNo tags attached.
tRAID Version 1.1
Attached Fileslog file icon FlexRAID.nzfs.log [^] (144,932 bytes) 2017-01-15 14:54
zip file icon [^] (2,543 bytes) 2017-01-19 20:05
png file icon CaptureSettings.PNG [^] (42,601 bytes) 2017-01-19 20:11

png file icon CaptureIDchange.PNG [^] (27,976 bytes) 2017-01-19 22:26

- Relationships

-  Notes
Brahim (manager)
2017-01-16 03:31

The Windows recycle bin feature should not be enabled on the pool disk.
Go to the recycle bin property and remove the pool disk from the set of disk it is enabled on.

Otherwise, the behavior will be as you describe. Windows has a problem showing the aggregate of the recycle bins as it expects only one universal unique identifier while it finds several (one for each the disks). This is a Windows Explorer issue that cannot be worked around short of creating a custom program that mimics it and understand the pool better.
adridolf (reporter)
2017-01-16 11:28

Okay, it's actually that simple (=> fixed/closed). Unfortunately it seems that the settings does not stick if the pool is stopped and restarted (so that the drive disappears in between; however, this is not your problem in my opinion).

Maybe you can add one or two lines about that to the quick setup guide (e.g. [^]), because although the solution is logical, it nothing you think about when setting everything up. (At least since I have never been able to start the pool with removable=true, otherwise it should be no problem anyways).

Unrelated side note: I set up a N-way mirror yesterday and had to deduce the set up process from user comments in the forum. Maybe you can write a small setup guide for that, too (Since there is no distinction between DRU and PPU there, I was not sure which disk is overwriting which).
adridolf (reporter)
2017-01-17 09:47

The recycle bin setting is not preserved during a restart (maybe because of the pool being unmounted in between).

I will try to find out whether I can build a script for resetting this during startup (which would be an acceptable solution for me).
adridolf (reporter)
2017-01-17 11:34

The reason why the settings do not stick is that on each mount of the pool it is assigned a new volume GUID. Consequently, it is treated as a new disk, while the old settings just fill up the registry (I have about 100 entries so far).

While one could still script around that (retrieve GUID based on drive letter, use regex and then set the registry values based on the result during each startup), I do not know whether it is really desirable to fill up the registry with dead volume entries. For me, doing one restart per day, this will reach 1000 in less than 3 years ... (only for the bin, I do not know what other entries are created)

Thus, if possible, it would be very nice if you could ensure the pool volume is registered with the same GUID after each start.
adridolf (reporter)
2017-01-17 13:01

For the momentary situation, I wrote a small C# program which is run during user logon. So in case you do not intend to provide a permanent GUID for the pool, this is an acceptable solution for the recycle bin to be disabled.

However, this won't stop the proliferation of GUIDs.
Brahim (manager)
2017-01-17 21:22
edited on: 2017-01-17 21:23

The GUID is actually not the issue. I extensively looked into resolving the issue of Windows not remembering the device shares to no avail so far.

I know why that is as I can make it work with the tRAID disks. It is just that the pool is different.

As far as the Windows recycle bin, try this:
1. stop the pool (not the array, just the pool)
2. add drive letters to the tRAID disks
3. empty the Windows recycle bin
4. disable the recycle bin on the tRAID disks
5. remove all drive letters
6. restart the pool

Let me know if that fixes things.

adridolf (reporter)
2017-01-17 22:22

No, the settings do stick for the individual tRaid disks but not for the pool. I also tried deleting the bin folders.

And, excuse my disagreement, I'm quite convinced that the issue is the Volume ID:
To my understanding, the drive settings of the recycle bin are saved in the following registry key:
Here you have one key for each volumeid of a hard disk. In those keys, there are the values MaxCapacity and NukeOnDelete for the bin's size and the on/off toggle, respectively. Based on the MaxCapacity of the pool, I can "count" how many entries for the pool I have. This is a number between 50 and 100, as I stated earlier.
When I now stop and start the pool, a new key with a new volumeID is created, and the child values MaxCapacity are set to their default values. If, however, the pool would have the very same volumeID as before, Windows would use the values in the corresponding existing folder, as the registry entries do actually stick.
(As consequence, my logon script works just by finding out the current volumeID of the drive by the correct drive letter and then by updating the newly created registry values for this ID.)
Brahim (manager)
2017-01-18 00:58

I see. Good info.
Let me research that and follow up later.
Brahim (manager)
2017-01-19 18:55

Hum... it looks like this issue might be system specific.

I testing on various systems including Windows Server 2012 R2. The volume GUID stays the same even across reboots.
So, not sure as to why it is changing on your setup.

Can you?
1. With the pool running, open a CMD prompt and type: mountvol >> guid-test.txt
2. Reboot
3. Start the pool, open a CMD prompt and type: mountvol >> guid-test.txt
4. Provide the output from both commands
adridolf (reporter)
2017-01-19 20:11

I did the following (zip file):
1. mountvol
2. reboot
3. mountvol
4. pool restart (array still running)
5. mountvol

The pool is drive K:. Note that even a simple stop/start of the pool (with the array and system still running) is sufficient to change the ID. Also note that the individual tRaid disks and my two-way mirror with drive letter I: do keep their IDs.

I also added a screenshot of the pool settings.
Brahim (manager)
2017-01-19 20:37

I see.

It is very strange that I cannot reproduce it on any of my test system.
This includes VM systems as well as physical systems.
Also, as stated, one of the systems is on W2k12 R2 (albeit NTFS instead of ReFS).

So, I am now wondering if it is a ReFS specific thing.
I haven't had time to re-setup my ReFS test environments. Are you able to create a sample array and pool that is all NTFS and see if the issue persist there?
adridolf (reporter)
2017-01-19 22:25

Okay, I tested with a set of three mounted vhdx image files (5 and 3 GB DRUs and 5 GB PPU), all on the same physical machine:

With any setup, I could (every single time) reproduce the very same behavior: pool ID changes on every pool restart, tRaid disk IDs stick even when the array is restarted.

I tested MBR+NTFS, GPT+NTFS, GPT+ReFS, always the same.

But note that you have to look very closely on the volume IDs: I typically had only one or two "letters" changing, so you might just overlook a change of the ID, especially if you query more than one device (maybe have a look at the screenshot). I did about 7 to 8 restarts where I thought it would work, until I finally recognized the ID was already changing.

(I always selected "Do Nothing" during initialization, as the parity should not matter, I hope)
adridolf (reporter)
2017-01-19 22:31

Side note:
As for my primary pool, I tried to mount with removable=true, but got an error message. (Since I already deleted the setup again, I cannot state its exact text.)
Brahim (manager)
2017-01-20 00:43

1. For my checks, I use WinMerge for comparing the GUID.

2. Mounting as removable is should not fail. Though I mount things as fixed for testing, I personally tend to stick to the pool mounted as removable. I find that Windows screws less with removable disks. The benefits include greater energy saving (less access to the source disks) and less issues overall as certainty low level operations are not attempted including no shadow data being put on the pool disk.

3. Starting to wonder if you are running an old version of the pool driver.
Please download [^]
Then find all references to cbfs and post the versions.
On my production system running W2k12 R2, there is only one entry and it is
Brahim (manager)
2017-01-20 00:50

FYI, we are polluting the original report.
A proper defect report was opened on the topic of GUID changing: [^]

So, follow up there for that issue.

- Issue History
Date Modified Username Field Change
2017-01-15 14:54 adridolf New Issue
2017-01-15 14:54 adridolf File Added: FlexRAID.nzfs.log
2017-01-16 03:31 Brahim Note Added: 0001698
2017-01-16 03:31 Brahim Assigned To => Brahim
2017-01-16 03:31 Brahim Status new => feedback
2017-01-16 11:28 adridolf Note Added: 0001699
2017-01-16 11:28 adridolf Status feedback => assigned
2017-01-17 09:47 adridolf Note Added: 0001703
2017-01-17 11:34 adridolf Note Added: 0001704
2017-01-17 13:01 adridolf Note Added: 0001705
2017-01-17 21:22 Brahim Note Added: 0001706
2017-01-17 21:22 Brahim Status assigned => feedback
2017-01-17 21:23 Brahim Note Edited: 0001706 View Revisions
2017-01-17 22:22 adridolf Note Added: 0001707
2017-01-17 22:22 adridolf Status feedback => assigned
2017-01-18 00:58 Brahim Note Added: 0001708
2017-01-19 18:55 Brahim Note Added: 0001709
2017-01-19 18:55 Brahim Status assigned => feedback
2017-01-19 20:05 adridolf File Added:
2017-01-19 20:11 adridolf Note Added: 0001710
2017-01-19 20:11 adridolf Status feedback => assigned
2017-01-19 20:11 adridolf File Added: CaptureSettings.PNG
2017-01-19 20:37 Brahim Note Added: 0001711
2017-01-19 20:37 Brahim Status assigned => feedback
2017-01-19 22:25 adridolf Note Added: 0001712
2017-01-19 22:25 adridolf Status feedback => assigned
2017-01-19 22:26 adridolf File Added: CaptureIDchange.PNG
2017-01-19 22:31 adridolf Note Added: 0001713
2017-01-20 00:43 Brahim Note Added: 0001714
2017-01-20 00:43 Brahim Status assigned => feedback
2017-01-20 00:48 Brahim Issue cloned 0000445
2017-01-20 00:50 Brahim Note Added: 0001715
2017-11-23 13:51 Brahim tRAID Version 1.0 => 1.1
2017-11-23 13:51 Brahim Status feedback => resolved

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker