So, I upgraded to 4.7 with no issues.

 

I'll check back and see what Gary finds out.  Is everyone still gung-ho about 5?

 

B.

So, I upgraded to 4.7 with no issues.

 

I'll check back and see what Gary finds out.  Is everyone still gung-ho about 5?

 

B.

 

Personally I think it's a no-brainer, though I know there are other opinions. As I mentioned early in this thread, far better to gracefully move to 5.0.5 at a leisurely pace as opposed to having a hardware issue and looking to the forums for support where you will likely be recommended to move to 5.0.5 anyways, but under less ideal circumstances.

So, I upgraded to 4.7 with no issues.

 

I'll check back and see what Gary finds out.  Is everyone still gung-ho about 5?

 

B.

I'd run with 4.7 for a while, do a couple non-correcting parity checks, (need unmenu for that) take a look at your drives smart status (unmenu myMain makes that easy) and keep an eye on your syslog for any errors. Most of the issues people seem to have with upgrades is trying to upgrade a non-healthy array, either they think it will fix an issue, or they just don't realize there is an issue until they've already upgraded. Unraid isn't like windows, it's very seldom, almost never, that upgrading to a new version will fix an issue.

Is everyone still gung-ho about 5?

 

No, not at all.  Personally, in your situation, I'd just run with v4.7 until you either (a) have a hardware failure and need to migrate to a new system  (not just a disk failure, which you could replace & rebuild);  or (b) you decide you want to use larger disks.

 

On the other hand, if you want to upgrade, there's no compelling reason not to.  The one advantage v4.7 has over v5 is the ability to restart emhttp without the need to reboot the system.  The unknown, of course, is whether or not v4.7 has the "share copy" bug ... which I'll try to confirm sometime this week -- but note that even if it does, upgrading to v5 isn't going to resolve it, as it's a known bug in v5 for sure.    I suspect it may even be in v6 (does anyone know that?).

 

I know several folks with 15-20 drive UnRAID v4.7 systems housing their media collections who have NO intention of upgrading ... the systems are rock-solid;  they have all the storage they're ever likely to need; and are very risk-averse ... and ANY upgrade is indeed some risk.    I built these systems for them a few years ago, and if I insisted, they'd upgrade ... but I'm not going to advise doing something that offers virtually no performance benefit on a system that's running perfectly.  The average uptime on these systems is over a year ... and those are simply due to power failures that exceeded the timeout value set in the UPS's.  (ALL the systems I build have a UPS -- I insist on it)

 

Is everyone still gung-ho about 5?

 

No, not at all.  Personally, in your situation, I'd just run with v4.7 until you either (a) have a hardware failure and need to migrate to a new system  (not just a disk failure, which you could replace & rebuild);  or (b) you decide you want to use larger disks.

 

On the other hand, if you want to upgrade, there's no compelling reason not to.  The one advantage v4.7 has over v5 is the ability to restart emhttp without the need to reboot the system.  The unknown, of course, is whether or not v4.7 has the "share copy" bug ... which I'll try to confirm sometime this week -- but note that even if it does, upgrading to v5 isn't going to resolve it, as it's a known bug in v5 for sure.    I suspect it may even be in v6 (does anyone know that?).

 

I know several folks with 15-20 drive UnRAID v4.7 systems housing their media collections who have NO intention of upgrading ... the systems are rock-solid;  they have all the storage they're ever likely to need; and are very risk-averse ... and ANY upgrade is indeed some risk.    I built these systems for them a few years ago, and if I insisted, they'd upgrade ... but I'm not going to advise doing something that offers virtually no performance benefit on a system that's running perfectly.  The average uptime on these systems is over a year ... and those are simply due to power failures that exceeded the timeout value set in the UPS's.  (ALL the systems I build have a UPS -- I insist on it)

 

I respect gary's opinion but mildly disagree.

 

With the known rebuild bug in 4.7, the fact that 4.7 is on a much earlier kernel, and the fact that 5.0.5 has proven itself very stable, I would suggest going to 5.0.5. If something goes south with 4.7, getting support on 4.7 is going to be harder and harder. I don't see what possible advantage there is to staying so far in the past. But it is certainly up to each user.

 

Once the user share copy bug is resolved, I will definitely recommend anyone using a version that has that bug upgrade to a version where it is fixed. I am hopeful LT will make the fix available in 32bit, but that will be up to them.

I definitely agree that if the user share bug is resolved, that's a major fix for v5 (or possibly just for v6).

 

What we don't know, however, is whether or not that's a bug in v4.7.  I plan to determine that later this week when I have a bit more time to experiment.  If it's NOT a bug in v4.7, that's a good reason to stay with that version for a system that doesn't need > 2TB support.    The "known rebuild bug" in v4.7 is trivial compared to the share bug ... and in fact is an edge case that rarely occurs, is trivially avoided (just don't write to the array during a drive rebuild), and has very minor consequences if it does occur (the single file that was written during the rebuild is corrupted).

 

Any update to this?  I'm on 4.7 and was getting weird issues with copying to the NAS, but I think it was related to the computer I was copying from (as it worked fine the other day).

 

I'll be out of town for a week, but then should I...

 

Update to 5.0.5?

 

B.

I put together a basic v4.7 setup a couple days ago; but haven't had time to experiment with it to confirm whether or not it has the same user share bug as v5 & v6.  But even if it does, upgrading won't help ... at least not until the issue is resolved.

 

It's trivial to avoid the issue however -- never copy a file from a disk share that belongs to a user share to that same user share.    i.e. if you have a user share named "Movies" that's on disk 1, 2, and 3, don't copy a file from \\Tower\disk1\Movies  to  \\Tower\Movies.    It can result in the complete loss of the file.    If, for some reason, you want to move files off of disk1, but keep them in the same share; then copy them from the disk share to another disk share -- e.g. copy from \\Tower\disk1\Movies  to  \\Tower\disk2\Movies.

 

I should be able to confirm whether or not this works the same way in v4.7 sometime next week; but I suspect it does.

 

 

It is almost certainly at bug that goes back to the beginning of user shares.

Back in town.  UPdate?

 

B.

Yes -- it's a bug in 4.7 as well.  The issue is that because of the unified view of the entire array as a single "disk" when using shares, programs and utilities don't realize that they're doing operations that are illegal.    If you were trying to copy a file from a folder to itself, they would realize that and not allow it.    But when you're copying it from a disk share to a user share (or vice-versa), the utility doesn't realize that because the paths are different ... i.e. \\Tower\MyShare  and \\Tower\disk2\MyShare.

 

There's a trivial way to avoid the issue => if you're moving files from one disk to another, ALWAYS reference the actual disks ... NOT the user share.

 

Tom has researched the issue. There are, so far, no great solutions. Tom is using a mix of out-of-the-box functionality and custom functionality for the user shares. And fixing this issue would require modifying the out-of-the-box functionality, which Tom is not planning to do. Alternatives include preventing the export of a disk share which many users would hate. I am afraid the final solution may be a firm warning.

 

Stay tuned though as I'm sure they'll be an official announcement. But, as Gary says, at least for now, don't copy from a disk share to a user share or from a user share to a disk share. Copy either disk share to disk share or user share to user share. (Or from disk mount point to disk mount point, or user mount point to user mount point.) That will keep you safe.

There is something to be said for if it ain't broke, don't fix it.  My PVR runs Win XP.  It is used for one function and it does it well.  But with that said, I would upgrade for the following reasons:

 

1. Now you can do a controlled upgrade.

2. When, not if, you have to replace a drive, you may as well go with a larger drive for the extra capacity.  If you have room now, I would replace the parity drive with a 4TB drive.  Then place the old parity drive in the system as a data drive.

3.  I am assuming your drives are SATA based.  . 

4.  I am also assuming your hardware can support drives larger the 2TB.

 

If items 3 or 4 are not true, I would stay at 4.7 until it starts to break, at which time I would build a new server and migrate all of my data

 

As far as the user share copy bug, I don't see it as that big a deal.  Yes I understand it and have been copying files between my disks since I had it.  It would be nice if the software would deny the command, but I can see why it does not.  I do believe it needs to be documented in the release notes along with the work around of only coping from disk to disk and not from user share to disk.  I feel, Unraid should display the release notes on first boot after an install/upgrade where all of the known bugs are identified and their severity plus any work around.  You then acknowledge the message and it does not display again until the next upgrade.  I read the release note myself, but a lot of people don't.

 

I do understand it could scare people off, but at least you told them about it.

I suspect the user share "bug" was a very rare occurrence until drives started getting so large that folks decided they wanted to reorganize their content to keep certain things together on the same physical disk ... thus started doing some moves of the data.    Even then, I'd think most folks would move from a disk to a disk -- not from a disk to a user share, simply because they didn't want UnRAID to determine where to move the files to.

 

In any event, it's a trivial thing to avoid ... I doubt there will be a "fix" other than simple education -- i.e. notes on the Shares page and perhaps in the release notes to be sure folks are aware of the implications.

 

I suspect the user share "bug" was a very rare occurrence until drives started getting so large that folks decided they wanted to reorganize their content to keep certain things together on the same physical disk ... thus started doing some moves of the data.    Even then, I'd think most folks would move from a disk to a disk -- not from a disk to a user share, simply because they didn't want UnRAID to determine where to move the files to.

 

In any event, it's a trivial thing to avoid ... I doubt there will be a "fix" other than simple education -- i.e. notes on the Shares page and perhaps in the release notes to be sure folks are aware of the implications.

I understand the issue and the reasons that it may not be able to be easily fixed (although Tom did mention investigating a different solution so I'm not completely giving up hope - but likely nothing in 6.0). But also agree that is is pretty easy to avoid if you understand it.

 

People reading Gary's comments need to know that he keeps full backups of his unRAID server. So his calculation of what is a "trivial" risk may be different than yours.

People reading Gary's comments need to know that he keeps full backups of his unRAID server. So his calculation of what is a "trivial" risk may be different than yours.

 

Whether or not you have backups has ZERO bearing on how much of a risk something is to the array.  It does, of course, make it a lot less stressful if you happen to do something risky and lose a bunch of data 

 

Just to clarify, I did NOT say this was a trivial risk -- clearly it's a significant data loss if you do the wrong thing.  [The word "risk" does not appear in my post.]    What I said was that it's trivial to AVOID the problem ... by simply copying from disk to disk.

 

People reading Gary's comments need to know that he keeps full backups of his unRAID server. So his calculation of what is a "trivial" risk may be different than yours.

 

Whether or not you have backups has ZERO bearing on how much of a risk something is to the array.  It does, of course, make it a lot less stressful if you happen to do something risky and lose a bunch of data 

 

Just to clarify, I did NOT say this was a trivial risk -- clearly it's a significant data loss if you do the wrong thing.  [The word "risk" does not appear in my post.]    What I said was that it's trivial to AVOID the problem ... by simply copying from disk to disk.

 

I would also assume the likelihood is pretty trivial for how long it went undetected. Given that in almost any scenario where you are moving data from one disk to another you wouldn't logically think to go from disk to a share.

I would also assume the likelihood is pretty trivial for how long it went undetected. Given that in almost any scenario where you are moving data from one disk to another you wouldn't logically think to go from disk to a share.

 

Agree.  Virtually anyone moving data is much more likely to think in terms of which disk they want to move from and which disk they want to move to => and use the disk references rather than a share they happen to be part of.    Clearly if this wasn't the case, the issue would have been noted LONG ago.    The only time you'd be likely to doing a share-based copy is if you're moving from one share to another share -- and that does not cause any problems.

 

I really don't see any reason to "fix" this issue -- just to be sure there is a notice that educates users about the consequences of attempting this action.

 

I would also assume the likelihood is pretty trivial for how long it went undetected. Given that in almost any scenario where you are moving data from one disk to another you wouldn't logically think to go from disk to a share.

 

Agree.  Virtually anyone moving data is much more likely to think in terms of which disk they want to move from and which disk they want to move to => and use the disk references rather than a share they happen to be part of.    Clearly if this wasn't the case, the issue would have been noted LONG ago.    The only time you'd be likely to doing a share-based copy is if you're moving from one share to another share -- and that does not cause any problems.

 

I really don't see any reason to "fix" this issue -- just to be sure there is a notice that educates users about the consequences of attempting this action.

 

As I was writing my post and trying to think through scenario's the one you mentioned was all I could think of as well, or moving data from one disk to another share completely, but these scenarios don't cause the issue, so it's moot.

 

 

... so it's moot.

 

Or at least nearly so -- there SHOULD be a warning on the Shares page that educates folks on this.  But I agree it's a VERY unlikely scenario that most users would never encounter even without a warning.

 

 

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.

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.

 

I was writing the same sentiment.

 

Who would think that EXPLICITLY telling unRaid on the setting page to exclude a disk from the share and getting no error would think that that disk is still in the user share? Very few I think. This defect is tricky to understand without understanding alot of the innards of how user shares are put together. For the unRAID user who just wants it to work, this is an accident waiting to happen.

 

I guarantee this will happen again - even with the warnings. The fact that it is trivial to avoid won't mean much to them.

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?

 

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.

 

... a bit more on this:  If you use the same "view" of the share, and try to do the same thing, it will work fine, but will simply append a suffix to the name.

 

For example, in Windows, if you select \\Tower\MyShare\Myfile and copy it to \\Tower\MyShare  it will work fine -- but the copy will be automatically named Myfile1.    Do it again and it will be named MyFile2.  etc.    But if you do that same thing from one of the constituent drives of the share ... e.g. \\Tower\DriveX\MyShare\Myfile and copy it to the share, the file will be destroyed (zero length).

 

If the goal is to move a bunch of data from a drive and let UnRAID reallocate it among the other drives in that share, all that's necessary is to (a) Exclude the drive from the share (or remove it from the list of Includes if you're using Includes);  and then (b) RENAME the folder on the drive you just excluded.    i.e. if it's a share named Movies, rename the folder to Movies2Move.    It will no longer be a part of the share -- and you can safely copy all of the contents to the Movies share and UnRAID will correctly distribute them across the share per the specified split level and allocation method.    When you're done, just delete the Movies2Move folder.