-
Notifications
You must be signed in to change notification settings - Fork 100
Removing a drive share incorrectly renumbers existing drives #320
Comments
I did a short test myself. NodeID, storage location etc are correct. I don't see a problem with the new drive numeration. Only one detail could be wrong: Lets label this issue as discussion and see what the other devs think about it. 2 error messages on the developer console -> #322 |
Could we also change the way log files are rotated? Currently, log files rotate on UTC, regardless of what the local machine's TZ is. Very confusing to see todays date as 7/31/16 but the log file is 8/1/16. ( #325 ) |
@utdrmac Please make a separate issue for that. There are over 100 open issues over the repos, so if its not in the title its going to get ignored. |
I did not test it, but what happens if you decrease the size of a current drive? |
@pvdl nothing will happen. The progress bar will show you max 100% and you will not get any new shards. After 90 days the first shards will expire and the used space will go down. |
Drives are tracked with a unique ID that is not shown to the user, so this is just a UX preference. The numbering is simply in the order of the list. The easiest solution here is to not use the numerical index to display, instead we can use the first few characters of the drive's ID. Both for the GUI display and the log file names. |
Versions
Expected Behavior
Drives/shares not to be renumbered
Actual Behavior
shares are renumbered
Steps to Reproduce
add multiple drives/shares. in my case, i had drive 0, 1, 2. I started 1 & 2. 0 was not running. in the drive menu you can see 0, 1 & 2. i deleted 0. i expected 1 & 2 to remain. this did not happen. 1 was renamed to 0 and 2 was renamed to 1.
The text was updated successfully, but these errors were encountered: