rename target not working with move (F6)

rich@pottruff · Post by **rich@pottruff** » 2009 Jan 25, 03:19

Hi.
I've been using the 'rename target' option lately when copying files.
it works fine.

I tried the option this past week with moving files (F6) and it does not rename it just overwrites.
I've tried this on two different machines to to make sure it was not my normal machine.
Is this the expected behavior? Or am i missing something?

thanx

fgagnon · Post by **fgagnon** » 2009 Jan 25, 04:15

If you are moving items between folders on the same drive partition, you should have seen a pop-up warning about that:

Robust operations are only supported for filesystem source and target folders. When moving files the destination must be on a different volume (drive).

The Transfer will be completed using normal windows functions, discarding any advanced options or filters.

... but you don't get the warning on subsequent occurrences if you checked the box to not show the message again. :shock:

rich@pottruff · Post by **rich@pottruff** » 2009 Jan 25, 04:36

Hi.
thanx for the quick answer.
You are correct. Once i thought about it all my file moves I was testing are on the same drive.

Guess I'll be copying and then deleting files.

thanx again.

fgagnon · Post by **fgagnon** » 2009 Jan 25, 15:26

nikos,

Please take this thread as yet another request to extend robust move to the "same drive" case.
Yes, we all know it will be slower; but we are willing to sacrifice speed for robustness.

Thanks, -fg-

Cosmo · Post by **Cosmo** » 2009 Jan 25, 17:34

fgagnon wrote:nikos,

Please take this thread as yet another request to extend robust move to the "same drive" case.
Yes, we all know it will be slower; but we are willing to sacrifice speed for robustness.

Thanks, -fg-

I will take the chance to give you another reason for that; interestingly (but by chance) at the same time, we talk about ending Win 9x support:

Doing PC-support there is a more or less standard-situation like this:

People have to make a fresh install of Windows, using NTFS as their file system. Luckily they have been able to save their data on another place of the harddisk. Suppose those people do, what they have been told again and again by security experts: they made for daily work a pc account with limited rights. Now they want to move the files with their data into the new pc account (somewhere in or below "My files" folder) and will fall into 2 problems: At first, they cannot remove the old files by using the move-command and at second they cannot even alter and not delete the moved files, although they are in their own account's tree. Absolutely typical situation where people get nervous.

The reason for that is simple: A moved file stays with the already set security settings, regardless of the target for the move-operation. And this means, that a limited user cannot alter the files that have been created by another user. Even if the account name was the same on the system before the new windows installation it is technically quite another account.

The problem is easy to solve (if the user knows), if the files get copied! (Deleting has later on to be made by somebody with admin rights, but this does not belong to here.) A copied file is for the file system the same as a quite newly created one (e.g. with F7 in x2): It belongs to the creator and the creator has all the rights that are possible.

What still to few people do know: Moving is technically on modern NTFS-systems a dangerous command with the possibility for several problems, which may result out of it. Users, who move, should have to have an expanded knowledge about file systems. In fact, mostly they do not have this knowledge and run into the traps.

X2 would have the option to support those situations, if robust move would be doable also inside a partition. I think it would be good, if at the first time the user gets a warning in such a situation (similar to now, but without the consequence of auto-disabling robust move), even better would be an option to enable / disable robust move on a single partition. As already said: It is slower, but it does things right, because technically it is a combination of copying and afterwards deleting.

Mr.Pleasant · Post by **Mr.Pleasant** » 2010 Apr 25, 20:11

I was looking on the forum if my point hadn't been mentioned before. This old thread was the closest I could find:
The filter-feature in robust transfers is not working when one tries to move files within the same partition.
I understand this is a consequence of X2's habit to use Windows move-function. As such it is quite obvious that the filters won't work in this scenario, but it was surprising to me (not in the last place because I never noticed it before, though I use filters regularly. Probably never with moving on the same partitions...

). It makes me convinced now as well that this is an anomaly.

fgagnon · Post by **fgagnon** » 2010 Apr 25, 20:35

@ It makes me convinced now as well that this is an anomaly. -

Some anomalies can be dismissed as

"OK, recognized, but nothing worth bothering about"

Others should be corrected.

Hopefully your intent is to point out you agree that
this one should be corrected to have x2 always perform robust transfers regardless of whether the destination is on the same partition as the source.

Mr.Pleasant · Post by **Mr.Pleasant** » 2010 Apr 26, 09:07

Yes, I think it should be corrected. It is quite surprising when you put a lot of effort in thinking of a good filter, and then, instead, everything is moved.

Post by **nikos** » 2010 Apr 26, 12:43

until that day that the feature is available you can do a robust copy followed by a robust delete with the same filter

Post by **nikos** » 2010 Apr 27, 07:35

i just remembered the real reason why i didn't add the robust move option: it would be much slower than a regular move! Compare plain delete with the robust delete and you'll see what i mean! Robust delete has to do 1 file at a time, even in subfolders so as to enforce filters etc. Normal delete on the other hand would remove a whole folder with all its contents in one quick operation.

so the same goes for robust move, it would take ages in comparison!

Kilmatead · Post by **Kilmatead** » 2010 Apr 27, 08:24

"Tii-ee-ime, is on my side, yes it is." According to the Rolling Stones, anyway. If "slower" means it actually works properly, I vote for slow. Mr. Pleasant is not the only one to impale himself on the fencepost of filtered Robustation.

Mr.Pleasant · Post by **Mr.Pleasant** » 2010 Apr 27, 14:25

I see what you mean, Nikos. In this case, the 'slow' way would be the fastest for me, with a big amount of large files to be sorted into new folders, and too little free space on my disc to make copies first.
That might be just 'bad luck' for me (and Kilmatead of course), but I'm also thinking of the breach in the GUI, when you can set up all kinds of robust settings, which are then disregarded when moving within the same partition. I can't think of any elegant solution to this, however :?