I guess I have avoided this issue by accident like most have. I only export user shares, and any addons also only use user shares. I have always done it this way because it just seemed the most logical and flexible. Once you have setup includes/excludes, allocation method, cache use, split level, why bother thinking about which disk? I think this would be a good policy for most users if they are going to enable user shares.

 

Conversely, if I am working at the command line or with mc, I always work with /mnt/diskx. The reason I am there in the first place is because I want greater control.

 

The most likely scenario (that I think may well have happened a few times recently) is when a user is trying to copy all files off a particular disk (which has been excluded from the share in its settings) and get them distributed amongst the files currently included in the user share.  It is not unreasonable to think that this would be the behaviour.

 

Okay, I thought this was a valid scenario, but in fact, if you are moving from a disk that's been excluded from the share then you can't have files copy over themselves, which I thought was the cause of the issue - if the source disk is excluded you can copy to the share as all data will move to another disk.

 

No?

 

No, this will indeed cause the issue.    Remember:  this issue is in essence copying a file from a folder back to the same folder.  The copy utility doesn't realize that's what's happening, so this very wrong operation is not flagged to the user, as it would be if you were doing this in Windows, Linux, MacOS, or any other OS.  It doesn't recognize this because of the fusing of the folders in the share into a single unified view that uses a DIFFERENT path to access ... so even though you're referencing \\Tower\DiskX\MyShare as the source, that SAME location is included in the unified view given by \\Tower\MyShare.    That's because includes/excludes ONLY apply to determining where to write new files.    From the copy utility's view, and the unified view of the share, this is NOT a new file -- so it will be overwritten in place, and truncated to zero length.

 

Ahh, gotcha. That makes sense. I forgot that even excluded disks will show up when browsing a share.

The issue is that the include and exclude settings only affect where new files added to the share can go. If you copy a file to the share that already exists in the share, it will overwrite the file wherever it is. So copying from the disk share to the user share will.be trying to overwrite itself and cause the data to be lost.

 

Even in this small group it is difficult to convey the message. Until this is fixed and fixed right it will be confusing.

 

I wonder if excluding the disk from the user share enablement screen would allow a user to do the intended - copy forum a disk share to a user share and have the user share spread the files based on normal rules. Renaming the user share root folder to a different name should also fix it.

The issue is that the include and exclude settings only affect where new files added to the share can go. If you copy a file to the share that already exists in the share, it will overwrite the file wherever it is. So copying from the disk share to the user share will.be trying to overwrite itself and cause the data to be lost.

 

Even in this small group it is difficult to convey the message. Until this is fixed and fixed right it will be confusing.

 

I wonder if excluding the disk from the user share enablement screen would allow a user to do the intended - copy forum a disk share to a user share and have the user share spread the files based on normal rules. Renaming the user share root folder to a different name should also fix it.

 

But usually why you would have a disk with share data on it, but exclude it from the share (for new share data) is if you have static data that you want to show up in the share, but not have that disk written to. For instance, if you have old TV shows you know are static because it's ended and you have every season/episode. I've stored these on excluded disks before, so they show up when browsing, but I can control what goes on that drive.

 

Renaming share folders would break this - which could be a good thing in that it eliminates one of the larger potential scenarios for this bug, or it could be a bad thing as it will break a process we've had for years.

 

Maybe on the share page it would make sense to have RW disks, RO disk, and excluded disks? If we could mark certain disks RO (just from the share folder down) and UnRAID could change permissions on that disk's share we wouldn't be able to re-write over them, which would give us the best of both worlds, no?

 

I wonder if excluding the disk from the user share enablement screen would allow a user to do the intended - copy forum a disk share to a user share and have the user share spread the files based on normal rules.

 

I haven't tested to confirm this, but Tom noted in one of his posts that if you exclude the disk from being available from shares on the GLOBAL shares setting page  [settings - Share Settings] that this would resolve the issue, since that disk is no longer looked at when fusing the shares.  But it seems just as simple (and perhaps less likely to have unintended consequences -- e.g. if you have other shares that use the same disk)  to simply rename the top-level folder.

 

 

Renaming the user share root folder to a different name should also fix it.

 

This absolutely resolves it -- it's no longer part of the share, so the issue disappears (I've confirmed this).

 

I haven't tested to confirm this, but Tom noted in one of his posts that if you exclude the disk from being available from shares on the GLOBAL shares setting page  [settings - Share Settings] that this would resolve the issue, since that disk is no longer looked at when fusing the shares.  But it seems just as simple (and perhaps less likely to have unintended consequences -- e.g. if you have other shares that use the same disk)  to simply rename the top-level folder.

 

If the goal is to remove the disk from the array, this would be a way to remove it from any and all user shares and not risk creating any new ones.

I haven't tested to confirm this, but Tom noted in one of his posts that if you exclude the disk from being available from shares on the GLOBAL shares setting page  [settings - Share Settings] that this would resolve the issue, since that disk is no longer looked at when fusing the shares.  But it seems just as simple (and perhaps less likely to have unintended consequences -- e.g. if you have other shares that use the same disk)  to simply rename the top-level folder.

 

If the goal is to remove the disk from the array, this would be a way to remove it from any and all user shares and not risk creating any new ones.

 

Agree.  But if you're simply moving data from one share because you no longer want it to use that drive, and will still have other data on the drive (perhaps in other shares), I'd think just renaming the top-level folder is simpler ... and less likely to inadvertently cause issues with the other shares.

It's also a better "habit" to have for when you want to move share data -- since it will always avoid the potential data loss of the "user share" issue ... whether or not you remember to change the global share settings.