version 1.1 final

[nikos]

i've just released the final version 1.1.0.0
www.netez.com/xplorer2
i'm keeping a low profile till next week when i'm back from ESWC
then i'll start full notifications

[pmike]

WOW!!!
Whatevery you did since the 1.0.0.x, keep it up.

My one _major_ frustration with xplorer2 was that navigating network shares (on first views, randomly afterwards) froze the program for 15-20 sec.

In fairness, regular explorer exhibited similar problems, but they weren't quite as severe.

1.1.0.0 is like greased lightning in comparison!
The robust file copy is awesome too...large copies accross the network don't freeze up x2!!

[kagaku]

I'm finding that the robust copy feature is quite useless, at least in it's current state. When I try and copy a file, instead of making a new file with the name Copy of foobar, it says foobar can't be replaced because the filename is identical. Could this be fixed in the next version please? I'd love to use robust copy in general usage.

I do have one small feature request as well: how about a progress bar? In my opinion, it's much easier to glance at a progress bar to see how much time is left rather then focusing on the actual numbers.

[fgagnon]

Robust copy is not intended for making duplicate copies of files already in a folder. It is primarily for jobs which require copying (or moving) many files from one location to another ... and it is AWESOME for that.

If all you need to do is make a second copy of a file in same directory, use the old standby Ctrl+C, Ctrl+V sequence on the selection (same as winExplorer) ... or use x2 Menu: Edit | Duplicate

As for a really good progress bar (or other indicator), some folks have been bugging nikos about that, and expect it will come eventually -- it's just not a high priority item right now.

added/
PS - Robust copy should either overwrite or skip identical files (depending on the options you have set) & do it seamlessly.
What, exactly are you doing to get the error? {which I cannot duplicate in v1.1.0.0}

[kagaku]

Hit Ctrl+C then Ctrl+V in the same directory, instead of the expected results (A copy of the file being made) it just errors out and says that the file can not be replaced because the filename is identical.

My question is, if robust copy is not indended for something as simple as making a duplicate of a file, what good is it? If I have to go through a few hoops to use it when Ctrl+C and Ctrl+V work just as well, why bother?

Personally I think it should be made the default for file copy/move procedures, as long as it's improved. I shouldn't need to go through the menu to duplicate a file when the default accepted behavior in windows is to press Ctrl+C/V.

[Thracx]

I was able to get what I believe to be kagaku's error. Select one file, push F5 (to get the robust copy dialog). Then select the destination to be the same as the origin - it will prompt you saying "Target cannot be identical to source name."

kagaku, if this is what you are refering too, then it is intentional. The robust copy function, as fgagnon said, is "primarily for jobs which require coping (or moving) many files from one location to another." Ctrl + C & V still yields the standard copy procedure - use that for most things, only call up the robust copy when you need to do large transfers.

What I think you are asking for is another feature/option in the robust options dialog. Currently you can tell xplorer2 to overwrite identical files, or prompt the user for a decision. You would like a third option - create a 'Copy of...' when identical files are encountered. This would then allow the robust copying mechanism to be the default copying method in xplorer2, even for Ctrl + C & P, which is what I believe to be what you would like.

[kagaku]

My point was primarily: why add stuff like this if they're no better then what they're replacing? The robust copy feature is great, but if it can't do everything the old function did while remaining simple it's useless.

xplorer2 should be intelligent enough to see that when I copy c:\testfile.txt to c:\textfile.txt, there would be absolutely no reason why I would want to overwrite the file. It should be obvious that I'm trying to make a duplicate of the file in the same directory. It should also be able to prompt me when encountering a file of the same name in a different directory, asking me if I wish to overwrite the file.

[Thracx]

My point was primarily: why add stuff like this if they're no better then what they're replacing? The robust copy feature is great, but if it can't do everything the old function did while remaining simple it's useless.

I'm afraid I don't follow you here. You ask "why add something that is no better than what they replace", yet immediately say that the "feature is great." If the feature is great, then surely it is better than what it was replacing! However, I think it better to venure the idea that the robust copy feature of xplorer2 is notmeant as a replacement for the standard windows copy function, but rather as supplementary to it.

I for one know the main of waiting on the windows copy to transfer a large amount of files, only to have it crash mid-way leaving the state/location of my data unknown. Not to mention the unaccurate time-remaining dialogs & lack of speed information of the windows copier. And although I haven't experienced this personally, I see how important this robust feature would be for networked folders.

It should also be able to prompt me when encountering a file of the same name in a different directory, asking me if I wish to overwrite the file.

This is provided already, check under the options for the robust copy - 'Ask Confirmation' is there and it is the default.

[fgagnon]

xplorer2 should be intelligent enough to see that when I copy c:\testfile.txt to c:\textfile.txt, there would be absolutely no reason why I would want to overwrite the file. It should be obvious that I'm trying to make a duplicate of the file in the same directory. It should also be able to prompt me when encountering a file of the same name in a different directory, asking me if I wish to overwrite the file.

@ absolutely no reason ... it should be obvious -
Unless it were a common error on the part of the user who intended to copy into a like-named folder on a different drive -- in which case the behaviour is preferred.

@ prompt me when -
Yes, I agree, now that I see it. This case is so specific (& easy to detect), it deserves a prompt for the user to choose between creating duplicates or changing the target directory. (Although the Ctrl+C, Ctrl+V sequence is familiar for making duplicates and is MUCH quicker than robust copy, which excludes the source folder from its target menu. So it requires specifically entering the target folder name or navigating to it -- both of which require more keystrokes. This is likely why the beta testers overlooked it -- we all know the easy way. )

[Thracx]

...it requires specifically entering the target folder name or navigating to it -- both of which require more keystrokes.

I would like to join kabaku on this one - any chance of making robust copy the DEFAULT copying mechanism? If what you said is implemented, then this could work wonders.

[fgagnon]

see registry.txt for how to make it the default (including for the Ctrl+C , Ctrl+V sequence). {add 0x20000 to the binMiscOptions variable}

But I won't do it myself until the above discussed special case is resolved -- & may not even then; because IMO making duplicates is a useful, but relatively trivial sidelight when working/editing/evolving a file (or a small group of files) and not a function for which I need a powerful robust copy tool when I want to be able to copy/update/move 000's of files from one place to another.

[Thracx]

...000's of files...

That many, really?!? heh..

But seriously, yes, making robust copy the default copying mechanism won't work now since you won't be able to make dups. I am not sure whether or not I will make it the default or not, I guess I'll make that choice when this special case is resolved.

[nikos]

ok here's a small bugfix 1.1.0.1:

www.ps.ic.ac.uk/~umeca74/interim11.zip

the help file was updated too

if you see any of the same problems persisting please let me know asap