nisemono wrote:I have uninstalled & reinstalled again using this process

1. Uninstall Storage Pool Driver
2. Close FlexRAID
3. Stop FlexRAID Services
4. Run FlexRAID Uninstaller
5. Removed services with sc delete FlexRAID and "sc delete "FlexRAID Disk Manager"
6. Deleted FlexRaid Folder Manually
7. Rebooted
8. Installed FlexRAID 2.0 R6
9. Setup config
-D:\
|-*Auto-Minimized-Folder-Split-Priority
10. Clicked Save
11. Clicked Preview (Shows up as expected)
12. Clicked Publish/(Re-)Start

I still end up with duplicates, interestingly when I refresh the root of the drive, sometimes it will show 4 duplicate Copies of different folders, 2 for others, only 1 for something else... which change on each refresh.

Screenshot attached, should I re-open the bug that was closed on the bug tracker or what should I try next?

nisemono wrote:Interestingly you'll note the structure the screenshot displays on the left hand pane has a different number of duplicates from the main window pane.

Yes I did that on day one I moved from WHS to SBS7 (it was a painful process with 12 disks). All my "share" folders are as much as possible in single disks. Cannot always be done though (when those folders are larger than a single disk). In fact when I moved to SBS7 a single "share" was split in two disks and right now, THREE shares are spilled in different disks (one extra disk per share), because my data outgrew my original disks.

Avoiding to spill all over, I am with you in this. That doesn't mean it shouldn't happen in a controlled way (when it cannot be avoided). For example unRAID has a certain priority (user chooses) to "spill" data and has provision for excluding disks from the spill.

In fact you allow for the same too! You just use your own hidden folders for the spills. Right?

You said it yourself above "splitting folders happens only if there is no other way to around it". Again I AM WITH YOU on this. What you are not with me/us, is expecting us to have made the decisions ourselves before setting up View (because well, there WAS life before View).

What you "deny" us, is to have our data PRE-arranged (we don't setup View on empty disks waiting to be filled, it's a fact of life) and for the system to just "follow" our arrangement. It's a bit like telling the user "you are stupid, you don't know how to arrange your own data", or "don't have your videos in two disks in folders named videos, because I want to use my _frxr_ instead, but if you insist you go and TELL me that you have two such folders and you want them as one... and I don't care if you have 20 folders in various depths of those two shares with same names, ha, go make explicit joins for them too".

In practice, as I said originally I found myself splitting a single root folder: "Videos". Easy enough for viewconfig.txt you would say. True. Then I found out that IN "Videos" there was in fact a SINGLE folder that was responsible for the split (and all other could be kept on a single disk). I arranged for that too and made an ADDITIONAL entry (in fact IIRC three extra lines) for explicitly merging that one subfolder in View. Then another root folder ("Disk Images"), up to this point fitting in a single disk... well I had to add data. TWO types of data that have to go to separate existing folders (in that same root folder... "Disk Images\Games" and "Disk Images\OS"), so guess what, I had to make the same root folder on a second disk AND the two folders under it. Then I had to add entries for ALL THREE explicit merges (about 10 extra lines - be the problem is not the math, it's that every time this happens I have to maintain it). Best would be to RE-arrange my data, so that the split could stay on the root folder (keep all Games on the first disk, but move all OS images on the second possible along with some other subfolder of Disk Images, so that Games fits in the first disk)... this would mean less extra entries in viewconfig.txt (you never get away with NO extra entries) but this would mean shift quite a few GB of data with the help of a third temp disk... No go. Then guess what... My "Emulators" root folder had to grow... Hope you get the point (it is not even fiction, it is my case).

Say all this just for the sake of discussion don't expect you to change your mind. You hopefully understand why I really CAN'T use View in its current form. Of course you didn't write View for me, but nevertheless I think I demonstrated a usage that I don't think I am the only one with it.

What I'd like to kindly "press" once more, is IF it is not too much additional code, in some distant version that you don't know what extra to add, to have a mode like that (make it unsupported or whatever), for people stupidly wanting to make their own splits and NOT tell the system explicitly about it (problem not being that it would be hard to add those tenths of extra lines, but would be hard to MAINTAIN them when something changes... and if a system makes your life more complex than before, why use it). Thanks.
(this last paragraph was not a question to be answered, just something to keep in the back of your mind)

(btw feel free to split those last posts between us, to a separate thread if you feel we mess this one)

Again thanks for reading (everybody).

NLS wrote:
...

(*) ...rendering all other solutions made in the past in a way as "stupid" ...pity I can't make that "bad choice" myself (in View) and not have to look for smart scripts to run periodically or manually fight possible folder duplicates that I need to define explicitly deep in my tree structure (and remake all this every time the balance changes) ...hope Brahim reconsiders some time in the future... I DO promise to re-read the explanation on why implicit merging is bad and understand it better (or at least a bit) - because right now frankly I can only say that it worked fine with unRAID and its few thousand users (me included) and also the other "view-like" windows implementation I am testing now, also works fine with "implicitly merging".

greatus wrote:wtf?