Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000431FlexRAID Transparent RAID[All Projects] Generalpublic2016-10-25 15:562017-11-23 14:00
Reporteradridolf 
Assigned ToBrahim 
PriorityhighSeveritymajorReproducibilityalways
StatusresolvedResolutionreopened 
PlatformWindowsOSWindows Server 2012 R2OS Version
Summary0000431: Moving files to local disk just deletes them
DescriptionWhen I move (not copy) files from the Storage Pool to another drive, the files are deleted from the storage pool, but only an empty folder is created at the destination.
The behavior is observed both when copying local and when accessing the storage pool as a network share. Deleted files are present in the universal recycle bin, since I enabled it.
Additional InformationOS caching off
TCQ on
SWO on
Direct I/O on
Profile PERFORMANCE
Removable false
STRICT_FOLDER_PRIORITY
All volumes and storage pool are ReFS
TagsNo tags attached.
tRAID Version 1.1
Attached Fileslog file icon FlexRAID.nzfs.log [^] (30,210 bytes) 2017-01-07 16:46
zip file icon testfolder.zip [^] (680 bytes) 2017-01-07 20:38
log file icon LogSecondPatch.log [^] (44,587 bytes) 2017-01-07 23:18
png file icon FileChangeDate.PNG [^] (6,166 bytes) 2017-01-07 23:52

- Relationships

-  Notes
(0001580)
adridolf (reporter)
2016-10-25 16:50

changed TCQ, SWO, Direct I/O, Profile and Folder policy -> Same behavior
(0001581)
adridolf (reporter)
2016-10-25 17:42

Local drive->Pool : works
Pool->Pool : works
Pool->Local drive : folders are empty, but files are moved
(0001582)
adridolf (reporter)
2016-11-28 10:58

Although I doubt anyone reads this at all, I just wanted to annotate that I observed no errors in the FlexRAID.nzfs.log at default logging level when the problem occurs.
(0001585)
Brahim (manager)
2017-01-04 04:33

This issue is fixed for the next release.
Additionally, a patch is being issued so that users do not need to update to the next release to see this resolved.

Please see http://forum.flexraid.com/index.php/topic,49155.0.html [^]
(0001624)
adridolf (reporter)
2017-01-07 16:45
edited on: 2017-01-07 16:47

Thanks for looking into this issue, since I really love your software and I'm glad it's still maintained.

Unfortunately, the path did not fix my particular issue, I'm still not able to move files from the storage pool to a "local" disk. I added a log file to the bug report, so maybe it is possible to further investigate the problem.

Note that after the procedure you indicated did not work, I already did a complete restart of the server which unfortunately did not alter the behavior.

The folder moved was named: "zTest - Copy (4)"

(0001626)
Brahim (manager)
2017-01-07 19:40

New build sent.
(0001630)
adridolf (reporter)
2017-01-07 20:46

I'm sorry, again no change of the behavior.

I added a copy of my test folder which is copied and then moved, in case it helps you testing or understanding. However, note that even a folder with one empty text file in it will be empty after being copied.

Side note: I could not replace the NZFSB.exe without restarting the machine, as the service still blocked it after stopping the pool (and the entire array later). When I then renamed the old executable, the service remained linked to the renamed old exe (on the OS disk with NTFS). Stopping/restarting the service in services.msc without restarting the machine seemed to break it (no start of the array possible), so I did not mess around further but did the mentioned server restart, having the service using the correct executable after the reboot.
(0001631)
Brahim (manager)
2017-01-07 20:58

1. It may take up to 30 seconds when stopping the broker service before you can replace its executable.

2. Can you take a screencast of your operations?

3. How are you executing the move?
My understanding is that you are doing a cut from the pool and paste into the other drive. Correct?
(0001633)
Brahim (manager)
2017-01-07 21:14

Also, looking at your logs, you do not have the correct binary running.
I see log entries that were added to the first patch but removed in the last patch.

Verify that the file has a digital signature dated as of today.
(0001634)
adridolf (reporter)
2017-01-07 21:24

Test sequence:
1. I log in to my server via (Microsoft) Remote Desktop
2. I copy the test folder on the storage pool so I do not have to create it for every test
3. I move the test folder via drag-and-drop from one Explorer window to another (source in on the storage pool, destination is on some other volume)
4. Result: Empty folder (with the correct name) on the destination, complete folder residing in the global recycle bin

Same happens when I move from the pool to the desktop (which is on C:, obviously)

BUT: USING POWERSHELL WORKS:
Move-Item sourcedir destdir

This works both locally at the server (when connected via Remote Desktop) and when accessing as a network share on my desktop machine (using UNC paths and without administrator privileges):
e.g. Move-Item \\host.example.org\ServerStorage\g D:\gg

Using the PowerShell approach, all moved files and folder additionally show up INDIVIDUALLY in the universal recycle bin (so directory tree is not preserved).

Everything described here is tested with the second patch (from January 7th).

Side note 1: The log was only provided after testing the first patch, I did not provide a more recent one.

Side note 2: What does ScreenCAST precisely mean? A video of the process?
(0001635)
adridolf (reporter)
2017-01-07 21:25
edited on: 2017-01-07 21:28

Despite Drag-and-Drop, Ctrl-X/Ctrl-V also does not work.

(0001636)
Brahim (manager)
2017-01-07 21:52
edited on: 2017-01-07 21:53

"3. I move the test folder via drag-and-drop from one Explorer window to another (source in on the storage pool, destination is on some other volume)"

It is not possible to move folders from one disk to another by merely dragging and dropping. Such operation will just copy the folder.
Moving folders by drag and drop only works for the same volume. That's how Windows has always behaved.

In my testing:
1. If I drag a folder with or without content from the pool to another disk, a copy of that folder and content is just made at the destination.
2. If I cut the folder from the pool and paste to another drive (including network shares), the entire folder is moved.

So yeah, a video recording of your operation might shed some clearly light.
Also, logs in TRACE mode for the current build being tested are important. So, please provide them.

(0001637)
adridolf (reporter)
2017-01-07 22:06

- If you press shift during drag-and-drop across drives, you can switch to moving. (Like you can switch to copying on the same drive by pressing Ctrl)

- Copying has always worked.

I will try provide a video and the logs soon.
(0001638)
adridolf (reporter)
2017-01-07 23:24
edited on: 2017-01-07 23:24

As attachments you can now find a video (avi/Xvid) and the corresponding part of the log files.

I tried to perform both Cut/Paste and PowerShell for you to be able to compare the log on those.

Please make private (if possible) or remove the video soon, as one can see my hostname in it.

Hope this helps to pin down the problem.

(0001640)
Brahim (manager)
2017-01-07 23:48

Could you please stop the pool, add drive letters to your tRAID disks (not the source disks, but those created by the array and then run:
fsutil fsinfo refsinfo <driveletter> (fsutil fsinfo refsinfo D:).

I want to know what version of ReFS your drives are formatted as.
Also, what file system do you have the pool set as?
(0001641)
adridolf (reporter)
2017-01-08 00:01

I definitely use the latest file (see the screenshot I added and subtract 7 hours (I think) of time difference).

All disks and the pool are ReFS, I never tried setting the pool to NTFS, as I do not know whether this would jeopardize my data.

Unfortunately, there is no refsinfo parameter on my system:

> fsutil fsinfo refsinfo R:

refsinfo is an invalid parameter.
---- FSINFO Commands Supported ----

drives List all drives
driveType Query drive type for a drive
ntfsInfo Query NTFS specific volume information
sectorInfo Query sector information
statistics Query file system statistics
volumeInfo Query volume information
(0001642)
adridolf (reporter)
2017-01-08 00:10
edited on: 2017-01-08 00:11

From quick research, the refsinfo parameter is only introduced in Server 2016. This seems to be also true for ReFS versions 2 and 3. So my version must be < 2.0, I actually don't know whether there are other subversions than 1.0 like 1.1 or so ...

I formatted all my ReFS drives using Windows Server 2012 R2.

(0001643)
adridolf (reporter)
2017-01-08 00:21

Based on this page (https://gist.github.com/0xbadfca11/da0598e47dd643d933dc [^]) my version should be 1.2.
(0001644)
Brahim (manager)
2017-01-08 05:55

PM sent on the forum.

The URB now has a compatibility mode, which this build defaults to.
A UI update is required for switching between modes.

The difference between this compatibility mode vs regular mode is that:
1. Folders aren't versioned in the URB (only the contained files are)
2. Deletion of folders with large amount of files is slightly slower
3. When moving content from the pool to an external volume, the files are still moved to the URB. Whereas, in regular mode, this is detected and the source data is simply deleted without being moved into the URB.
(0001648)
adridolf (reporter)
2017-01-08 15:25

This update seems to work in all scenarios:
- Move connected via Remote Desktop and using PowerShell
- Move connected via Remote Desktop and using Drag and Drop/Ctrl+X/+V
- Move from network share (pool) to local drive from another machine (Drag and Drop)

In every case, the moved data showed up at the destination and in the universal recycle bin, where the latter had the correct folder structure (without the numbers (versioning?) on the folder AND subfolders, but present on the files.
(0001649)
Brahim (manager)
2017-01-08 16:17

Great. Thanks for confirming the fix.

Yeah, in compatibility mode, only files will have numbers appended to them (versioning) and not folders.

In regular mode, both folders and files are versioned.

There will be an update to the URB to make emptying it and restoring files logical. It will be a Web UI feature or shell extension or maybe both.
Even though content might have versions on them, I want that not be shown when the user browses the URB. Instead, I want the user to have a logical versioned view of the content.

Still working on the visual design part of this feature as I am trying to fight some cons.
Example:
1. Doing it a the Web UI will be consistent but will require users to open up a browser to access the feature.
2. Doing it a the shell extension level will limit the feature to Windows Explorer only. This won't even be portable to Linux. Additionally, the shell extension is only for the system that has the pool installed. Client systems whether Windows or not, will have not have the shell extension.

So far, I am leaning toward a Web UI implementation only for ease and consistency.

Thoughts?
(0001650)
adridolf (reporter)
2017-01-08 16:41

Regarding the planned feature(s) in general: That's great, because at the moment this is exactly what I miss with the current solution.

Regarding file versioning vs. folder versioning: Before the patches, when ONLY folders were versioned (in their folder names, but file names were regular), I was able to undo a delete by just moving and renaming the folder with all its files from the bin to its previous directory. Now in compatibility mode this is no more possible, as I would have to rename each file in the structure (problematic especially with lots of subfiles, even with a script). As a consequence, the compatibility mode does require an interface for restoring, as this would be hard to do manually.

Regarding your question (web vs. local):
I would also prefer the web version, as this is easily accessible and system-independent. I would hesitate to install another explorer extension to all my client systems just for that (while the web server just means one install and a proper IP access limitation). Eventually, using the bin will be a rare task compared to the direct access of the files, so logging in to the web interface would not be such a drawback.
However, I would like to also have (direct) file level access to the recycle bin like at the moment. This would provide a two level solution, with the "nice" interface via the Web UI and if necessary directly through the .@RECYCLER$. I would not like this direct access being removed completely for the sake of the nicer interface.
(0001653)
adridolf (reporter)
2017-01-08 17:26

Side note: I just realized that the compatibility mode also does not keep track of deleted EMPTY FOLDERS. They are just deleted and do not show up in the recycle bin (which is somewhat logical to me).

This is acceptable, but obviously it would be better if the showed up (although of low priority).
(0001654)
Brahim (manager)
2017-01-08 17:37

Compatibility mode does indeed delete empty folders as it does not version folders.

Having to rename all these files versus just the parent folder makes compatibility mode a PITA. Being able to navigate to the URB folder and move content back is something I see users doing more so than going to the Web UI.

I wonder whether ReFS 3.0 behaves better and more like NFTS in regular mode.
I have validated on several systems that regular mode works fine when the pool and disks are NTFS.

My ReFS test VM is currently decommissioned, and I need to setup a new one, which I will do in the coming week or two. So, I'll update later on the one issue of regular mode on ReFS.

To recap:
1. The only known issue is, moving folders from a ReFS pool to an external disk causes content to be moved to the URB and not properly being copied to the destination.
2. Regular copying from the pool to an external destination work just fine. So, one can first copy and then delete to work around this limitation.

I think regular mode is still usable on ReFS despite the one limitation since it is a rare operation and has an alternative.
(0001657)
adridolf (reporter)
2017-01-08 17:52
edited on: 2017-01-08 17:52

Regarding ReFS:
As I do not like Windows 10 in any way, I will most probably stick to Win 8.1 and Server 2012 R2 for some years at least, so ReFS > 1.2 is no option to me. From today's perspective, I would not use ReFS any more, as it introduces too many compatibility issues. However, transferring my 9 TB data and reformat back to NTFS is also no option.

Regarding Recap:
Technically, you're right. I mostly did a move in the way you described (copy and delete), but the problem is that during everyday work you just don't think of the issue. So you move some files and somewhat later you think "ow, I should have known". So if I had to choose at the moment, I would choose the compatibility mode for my future use.

(0001658)
Brahim (manager)
2017-01-08 19:22

I hear ya. All my serious systems are Win 7 and Win 8.1. It will be a while before I fully adopt Windows 10 outside of testing.

As far as the bug, considering that no data is actually lost, I think it is more of an annoyance than anything.

The combo of the operation being just rare (for me at least) + being able to go to the URB and copy the content makes this a truly minor odd behavior.
No question that it needs resolution, but I think it is livable till a proper fix.

I see two annoyances that need resolution:
1. Odd behavior when moving from ReFS pool to external disk
2. Painful restore from URB when in compatibility mode

Between the two, number 2 would be more annoying to me when encountered.
(0001661)
adridolf (reporter)
2017-01-09 13:58

Obviously the choice is also affected by the availability of the recycle bin interface you talked about and whether it will work in compatibility mode. Without this, on a second thought, maybe you are right and number 1 is better. However, if you decided to postpone a proper fix, I would also think about writing a small script/program to undo the versioning after having copied back. In any case, best would be a switch for compatibility mode in the Web UI, as you proposed earlier.

(It still is an annoying annoyance, although it is of much less impact to my daily work than the Mercurial issue. If the latter would be resolved, I could live with both of the annoyances above.)
(0001663)
adridolf (reporter)
2017-01-09 14:17

BTW: One disadvantage of the regular recycle bin mode is that individual deleted files show up the bin's root, so you can not find out where they came from (because no path is shown).
In compatibility mode, files are put into their correct directory tree, which is actually an advantage in this case.
(0001665)
Brahim (manager)
2017-01-09 14:52

Files being at the root is to mimic other recycle bin implementations, which behavior I agree with.

To have all individually deleted files in a folder structure would require that no folder is versioned. Versioning the root folder for each deletion would create too many versioned folders at the recycle bin root and require navigating through each to see the files.

This is actually a con of compatibility mode even with no versioned folder. One has to navigate through every sub-folder to get a complete view of the delete operations.
(0001676)
adridolf (reporter)
2017-01-10 13:09

Having used the compatibility mode a little longer now, I increasingly tend to agree to your earlier statement that regular mode with the moving files issue is preferable. ;-)
(0001728)
adridolf (reporter)
2017-02-09 12:08
edited on: 2017-02-09 12:19

Current state on the moving files problem WITH THE PREVIEW FROM 2017-01-28:

Scenario 1: Accessing pool via network share and moving folder to local drive (drag and drop)
-> Folder structure is preserved during move (=successful)
-> moved files do NOT show up in the URB (which I would call reasonable behavior)
= desired behavior

Scenario 2: Accessing pool locally (via Remote Desktop) and moving folder to non-FlexRaid drive (drag and drop)
-> Target folder is empty
-> moved folder and subfiles DO show up in the URB
= earlier behavior

Scenario 3: Accessing pool locally as in Scenario 2 but moving files with PowerShell's MoveItem
-> Target folder is created and complete
WRONG:
-> the URB only contains the moved folder without subfiles/-folders
CORRECT (EDIT):
-> the URB contains all subfiles and -folders as individual entries, indicating that they are moved and deleted sequentially by the command

In any case, although the current behavior is somewhat erratic, it is much preferable to the previous situation, as network share access is the most common usage scenario for me and no data is lost in any configuration.

(0001741)
Brahim (manager)
2017-11-23 14:00

Resolved in release 1.1 2017-11-22

- Issue History
Date Modified Username Field Change
2016-10-25 15:56 adridolf New Issue
2016-10-25 16:50 adridolf Note Added: 0001580
2016-10-25 17:42 adridolf Note Added: 0001581
2016-11-28 10:58 adridolf Note Added: 0001582
2017-01-04 04:33 Brahim Note Added: 0001585
2017-01-04 04:33 Brahim Status new => resolved
2017-01-04 04:33 Brahim Resolution open => fixed
2017-01-04 04:33 Brahim Assigned To => Brahim
2017-01-07 16:45 adridolf Note Added: 0001624
2017-01-07 16:45 adridolf Status resolved => feedback
2017-01-07 16:45 adridolf Resolution fixed => reopened
2017-01-07 16:46 adridolf File Added: FlexRAID.nzfs.log
2017-01-07 16:47 adridolf Note Edited: 0001624 View Revisions
2017-01-07 19:40 Brahim Note Added: 0001626
2017-01-07 20:38 adridolf File Added: testfolder.zip
2017-01-07 20:46 adridolf Note Added: 0001630
2017-01-07 20:46 adridolf Status feedback => assigned
2017-01-07 20:58 Brahim Note Added: 0001631
2017-01-07 20:58 Brahim Status assigned => feedback
2017-01-07 21:14 Brahim Note Added: 0001633
2017-01-07 21:24 adridolf Note Added: 0001634
2017-01-07 21:24 adridolf Status feedback => assigned
2017-01-07 21:25 adridolf Note Added: 0001635
2017-01-07 21:28 adridolf Note Edited: 0001635 View Revisions
2017-01-07 21:52 Brahim Note Added: 0001636
2017-01-07 21:52 Brahim Status assigned => feedback
2017-01-07 21:53 Brahim Note Edited: 0001636 View Revisions
2017-01-07 22:06 adridolf Note Added: 0001637
2017-01-07 22:06 adridolf Status feedback => assigned
2017-01-07 23:17 adridolf File Added: f1_xvid.zip
2017-01-07 23:18 adridolf File Added: LogSecondPatch.log
2017-01-07 23:24 adridolf Note Added: 0001638
2017-01-07 23:24 adridolf Note Edited: 0001638 View Revisions
2017-01-07 23:30 Brahim File Deleted: f1_xvid.zip
2017-01-07 23:36 Brahim Note Added: 0001639
2017-01-07 23:36 Brahim Status assigned => feedback
2017-01-07 23:37 Brahim Note Deleted: 0001639
2017-01-07 23:48 Brahim Note Added: 0001640
2017-01-07 23:52 adridolf File Added: FileChangeDate.PNG
2017-01-08 00:01 adridolf Note Added: 0001641
2017-01-08 00:01 adridolf Status feedback => assigned
2017-01-08 00:10 adridolf Note Added: 0001642
2017-01-08 00:11 adridolf Note Edited: 0001642 View Revisions
2017-01-08 00:21 adridolf Note Added: 0001643
2017-01-08 05:55 Brahim Note Added: 0001644
2017-01-08 05:55 Brahim Status assigned => feedback
2017-01-08 15:25 adridolf Note Added: 0001648
2017-01-08 15:25 adridolf Status feedback => assigned
2017-01-08 16:17 Brahim Note Added: 0001649
2017-01-08 16:17 Brahim Status assigned => feedback
2017-01-08 16:41 adridolf Note Added: 0001650
2017-01-08 16:41 adridolf Status feedback => assigned
2017-01-08 17:26 adridolf Note Added: 0001653
2017-01-08 17:37 Brahim Note Added: 0001654
2017-01-08 17:52 adridolf Note Added: 0001657
2017-01-08 17:52 adridolf Note Edited: 0001657 View Revisions
2017-01-08 19:22 Brahim Note Added: 0001658
2017-01-09 13:58 adridolf Note Added: 0001661
2017-01-09 14:17 adridolf Note Added: 0001663
2017-01-09 14:52 Brahim Note Added: 0001665
2017-01-10 13:09 adridolf Note Added: 0001676
2017-02-09 12:08 adridolf Note Added: 0001728
2017-02-09 12:09 adridolf Note Edited: 0001728 View Revisions
2017-02-09 12:10 adridolf Note Edited: 0001728 View Revisions
2017-02-09 12:11 adridolf Note Edited: 0001728 View Revisions
2017-02-09 12:19 adridolf Note Edited: 0001728 View Revisions
2017-11-23 14:00 Brahim tRAID Version 1.0 => 1.1
2017-11-23 14:00 Brahim Note Added: 0001741
2017-11-23 14:00 Brahim Status assigned => resolved


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker