Community
Participate
Working Groups
I've been testing super transfer and it's got some bugs still. Super transfer bugs: Bug #202668 - Subfolders not copied when doing first copy from dstore to Local Bug #191370 - Supertransfer zip not deleted when canceling copy Bug #202670 - After doing a copy to a directory that contains folders some folders name's display "deleted" Bug #200735 - Copy doesn't use latest changes if you copy a folder a second time and have made changes I've also run into problems where I get a message after doing a copy that the supertransfer zip was not deleted. I can't reproduce it consistently though. We shouldn't have super transfer enabled by default as it's still not in a state that works as well as normal copy. -----------Enter bugs above this line----------- TM 2.0.1 Testing installation : eclipse-SDK-3.3 RSE install : Dev Driver java.runtime : Sun 1.5.0_11-b03 os.name: : Windows XP, Service Pack 2 ------------------------------------------------
There is a typo in the bug description. The list of bugs opened for supertransfer should be: Super transfer bugs: Bug #202668 - Subfolders not copied when doing first copy from dstore to Local Bug #191370 - Supertransfer zip not deleted when canceling copy Bug #202670 - After doing a copy to a directory that contains folders some folders name's display "deleted" Bug #242674 (bug # is not correct) - Copy doesn't use latest changes if you copy a folder a second time and have made changes. And bug #242674 is a duplicate (caused by the same problem) of bug #202668.
Ha, I had the typo too! This is the updated text: The list of bugs opened for supertransfer should be: Super transfer bugs: Bug #202668 - Subfolders not copied when doing first copy from dstore to Local Bug #191370 - Supertransfer zip not deleted when canceling copy Bug #202670 - After doing a copy to a directory that contains folders some folders name's display "deleted" Bug #202674 (bug # is not correct) - Copy doesn't use latest changes if you copy a folder a second time and have made changes. And bug #202674 is a duplicate (caused by the same problem) of bug #202668.
Supertransfer was disabled by default in the TM 2.0 Preferences, so the question is whether it can safely be enabled for TM 2.0.1. This affects dstore and local only, since dstore and local are currently the only ones which are capable of doing archive handling (which is a requirement for supertransfer). I also think that supertransfer only gives performance improvements over plain copy, when copying across connections; so we're only talking about local <-> dstore and dstore <-> dstore transfers of folders or multiple files. I'll leave it to the IBM'ers to decide whether supertransfer should be enabled by default in 2.0.1 or not. The decision should be documented in the build notes / readme, so I'm putting the noteworthy keyword on this.
Supertransfer was not set as default in 2.0 is a workaround we had when we found it did not really work in very late cycle of 2.0. Please see bug #191367 for more details. But since it was not set as default in 2.0, and in 2.0.1 release we suppose to just fixing bug instead of changing the behaviour, I am ok with not setting it as default. But the fix I made still need to be in 2.0.1 since user could always check it as default by using the Preferences page. We could enable it in 3.0 release. Dave, what do you think?
I think we should leave the default as not enabled to avoid risk. Super transfer is not a requirement for the IBM products - it's merely a performance enhancement. We can change the default in 3.0 once the feature is stable and well tested.
Created attachment 78232 [details] not setting supertransfer as default.
Dave, Could you please review it? Thanks.
It is fixed in 2.0.1 RC1 driver.
Verified supertransfer is disabled by default in 2.0.1RC1. Thanks Xuan.
