Buggy controls

[tmpuser0]

Ultracopier 1.4.1.1/Win7 64. Copy engine > Performance controls act weird.

Program adjusts buffers to block size, but in a strange, buggy way. There doesn't seem to be a consistent ratio; as you play with different values, you can end up with different buffer sizes for the same block size.

For small block sizes (<64), seq. buffer size retains large values and jumps up and down as you increment block size by one.

Example: enter block size 1024KB, then change it to 32. Seq. buffer doesn't change. As you increment block size by one, seq. buffer size will start getting strange, fluctuating values that go up and down.
Another example: enter block size 4096. Program sets seq. buffer to 4096. Change block size size to 8192. Seq. buffer changes to 8192. Change block size back to 4096. Seq. buffer doesn't change back but remains 8192.

As sugar on top, Restore Defaults button doesn't work. It does nothing.

If something so simple and elementary is broken, there is no way I can trust this software with something as sensitive as copying data. Copy engine might be flawless but I'm not going to risk it to find out. Also, the options are undocumented, in the program itself or the wiki. I guess I'm supposed to consult the crystal ball about optimal buffer sizes and the number of inode threads. Not to be all negative, this software seems to be good at what it does and has great potential. But the interface needs to be much more professional if you want a wide user base.

[alpha_one_x86]

Hi,

I will check every thing mentioned. Each settings is separated. When change one, no other will change.
I will document more this themes.

inode thread > 1 can be risked, it's why disabled by default (risk of dead lock)

About data security:
https://ultracopier.first-world.info/articles/security-speed-ultracopier-supercopier-teracopy-copyhandler.html
All seam good but I understand yours fears.

EDIT1: http://ultracopier-wiki.first-world.info/wiki/Copy_specific_options -> more info added, bug about default the option seen, I will fix it
EDIT2: the reset will be fixed into 1.4.1.2

[tmpuser0]

Thank you for the quick reply.
If inode threads > 1 is unsafe, you should definitely document it and add a warning in GUI because many people will assume more is better and will increase the value without even knowing what it does.
I copied 3 TB of data with UC today without errors so I will continue using it. I wish you success with further development.

[tmpuser0]

I updated to v1.4.1.2 and noticed the following problem: on every program start, sequential/parallel buffer sizes are reset to value that is identical to block size. It is impossible to keep user set values as they will be reset on reboot.

[alpha_one_x86]

You are in right, I will fix for the next minor version

[alpha_one_x86]

Fixed

Note: all the version was checked by winmerge and other integrity software.

[tmpuser0]

User values are retained now but the way fields are populated is still buggy. When I enter 1024KB block size, program automatically sets seq. buffer to 2048KB but when I hit Reset Defaults, it sets seq. buffer to 131072KB for 256KB block size. It's not a big issue for me personally; at this point I accepted that GUI is half-baked, but if you're hoping to leave the impression of serious software, these quirks will need your proper attention.

[alpha_one_x86]

when I hit Reset Defaults, it sets seq. buffer to 131072KB for 256KB block size

It's the desired behavior.

I do this software on my free time.

[tmpuser0]

If you're saying 128MB is the recommended buffer for 256KB block size, then a 2MB buffer for 1MB block size seems disproportionately low. When you enter 256KB block size manually, buffer is set to 4MB, not 128, so if you say Default button's behavior is desired, this one must be undesired.

It seems like an issue than can impact copy performance so hopefully you will find the time to resolve it, for the sake of your software's success.

I was just trying to help with feedback. Kind regards.