|Anonymous | Login | Signup for a new account||2018-08-18 02:49 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000444||FlexRAID Transparent RAID||[All Projects] General||public||2017-01-15 14:54||2017-11-23 13:51|
|Platform||Windows||OS||Windows Server 2012 R2||OS Version|
|Summary||0000444: Deleted files end up in drive recycle bin|
|Description||When 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 Reproduce||Delete a file on the machine where the pool is running|
|Additional Information||I 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 NZFSB_Standard_URB_Extra_Logs_2017-01-12.zip 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).
|Tags||No tags attached.|
|Attached Files|| FlexRAID.nzfs.log [^] (144,932 bytes) 2017-01-15 14:54|
mountvollog.zip [^] (2,543 bytes) 2017-01-19 20:05
CaptureSettings.PNG [^] (42,601 bytes) 2017-01-19 20:11
CaptureIDchange.PNG [^] (27,976 bytes) 2017-01-19 22:26
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.
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. http://wiki.flexraid.com/2014/07/27/transparent-raid-quick-setup-guide/ [^]), 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).
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).
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.
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.
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.
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.)
I see. Good info.
Let me research that and follow up later.
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.
1. With the pool running, open a CMD prompt and type: mountvol >> guid-test.txt
3. Start the pool, open a CMD prompt and type: mountvol >> guid-test.txt
4. Provide the output from both commands
I did the following (zip file):
4. pool restart (array still running)
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.
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?
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)
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.)
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 http://www.nirsoft.net/utils/driverview.html. [^]
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 184.108.40.206.
FYI, we are polluting the original report.
A proper defect report was opened on the topic of GUID changing: http://bug.flexraid.com/view.php?id=445 [^]
So, follow up there for that issue.
|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: mountvollog.zip|
|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|