XYplorer Beta Club

Posted: **26 Jul 2011 01:53**

for the moment i'm not against of Move as Copy+Delete source. but i think it will need to be another button for settings added in >File Operations.

iycgtptyarvg wrote:When I move the files, I want them to be named xyz.cbr, xyz_01.cbr, xyz_02.cbr. Even though I move the files, I still have use for the renaming part.

but that is a copy operation prerogative, not a move's one

am i wrong?

Posted: **26 Jul 2011 09:34**

Assume having these 2 files:
D:\Comicbooks\Checking\abc.cbr
D:\Comicbooks\Done\abc.cbr

After checking D:\Comicbooks\Checking\abc.cbr I move it to the D:\Comicbooks\Done directory. Because there already is a file called abc.cbr it should rename it to abc_01.cbr.

Assume having these 3 files:
D:\Comicbooks\Checking\abc.cbr
D:\Comicbooks\Done\abc.cbr
D:\Comicbooks\Done\abc_01.cbr

After checking D:\Comicbooks\Checking\abc.cbr I move it to the D:\Comicbooks\Done directory. Because there already are files called abc.cbr and abc_01.cbr it should rename it to abc_02.cbr.

So, I would really like the move to work like the copy (the renaming part, that is).

Posted: **26 Jul 2011 10:54**

eil wrote:for the moment i'm not against of Move as Copy+Delete source. but i think it will need to be another button for settings added in >File Operations.
iycgtptyarvg wrote:When I move the files, I want them to be named xyz.cbr, xyz_01.cbr, xyz_02.cbr. Even though I move the files, I still have use for the renaming part.
but that is a copy operation prerogative, not a move's one am i wrong?

I'd understand it this way:

An intrapartition move is only a rename. (The unchanged physical data on disk just gets another name.)
If the new name already exists, it should (if requested!) be modified - but then it's still only a "modified rename". Still no physical data is copied on disk.

Or am I wrong somewhere?

Posted: **26 Jul 2011 11:17**

PeterH wrote:Or am I wrong somewhere?

I agree 100%.

Posted: **26 Jul 2011 12:17**

PeterH wrote:I'd understand it this way:
An intrapartition move is only a rename. (The unchanged physical data on disk just gets another name.)
If the new name already exists, it should (if requested!) be modified - but then it's still only a "modified rename". Still no physical data is copied on disk.
Or am I wrong somewhere?

for me that's not correct.

whether it's an intra-volume move(logic of which i know) or a cross-volume, it's "handled"(visually, for user) as one Move command.
all the names to these commands were given for some purpose, so: when i want to rename i Rename; when i want to get a duplicate i Copy(with same name if cross-volume and rename/increment if intra-volume); when i want to move i Move(if it's cross- file must be gone at the source, if it's intra-, or more precisely even same path, nothing at all should happen).

Posted: **26 Jul 2011 13:15**

eil wrote:
PeterH wrote:I'd understand it this way:
An intrapartition move is only a rename. (The unchanged physical data on disk just gets another name.)
If the new name already exists, it should (if requested!) be modified - but then it's still only a "modified rename". Still no physical data is copied on disk.
Or am I wrong somewhere?
for me that's not correct. whether it's an intra-volume move(logic of which i know) or a cross-volume, it's "handled"(visually, for user) as one Move command.
all the names to these commands were given for some purpose, so: when i want to rename i Rename; when i want to get a duplicate i Copy(with same name if cross-volume and rename/increment if intra-volume); when i want to move i Move(if it's croos- file must be gone at the source, if it's intra-, or more precisely even same path, nothing at all should happen).

It gets a little bit confusing: an intra-partition move is basically shuffling a pointer in the MFT (the file system administration) from one folder to another. Based on that, I wouldn't call it a rename.

If XYplorer encounters a name collision (there's already a file of that name in the move's destination folder) then Custom Copy will optionally rename the source item before moving it in the destination folder, as well.

Posted: **26 Jul 2011 23:07**

eil wrote:
PeterH wrote:I'd understand it this way:
An intrapartition move is only a rename. (The unchanged physical data on disk just gets another name.)
If the new name already exists, it should (if requested!) be modified - but then it's still only a "modified rename". Still no physical data is copied on disk.
Or am I wrong somewhere?
for me that's not correct. whether it's an intra-volume move(logic of which i know) or a cross-volume, it's "handled"(visually, for user) as one Move command.
all the names to these commands were given for some purpose, so: when i want to rename i Rename; when i want to get a duplicate i Copy(with same name if cross-volume and rename/increment if intra-volume); when i want to move i Move(if it's cross- file must be gone at the source, if it's intra-, or more precisely even same path, nothing at all should happen).

The names "move" or "copy" were given for some level of understanding, but not for the real function behind that.

The problem here is that we see a file as the meaning of it's name: the (full) name seems "to be" that file. But that's not true: the file is the data somewhere on disk, and the name is only a pointer to it. *One* file even may have two or more names, i.e. c:\a.txt and c:\x\y\z\b.save. Both names *seem* to be in different levels of the file system, but both are just pointers to the same blocks of data on disk.
And so an intra-partition move is, as nas8e9 says, nothing but a change of pointers to the same data - the data isn't touched ("moved") in any way. (That's why such a "move" is so fast, no matter how big the file is.)

And to the difference of (intra-partition) renames and moves: it only is what we see, nothing internal!
For a rename we change the lowest level of the full name, e.g. c:\x\a.txt to b.txt (for sure also "in c:\x\").
For a move we change what we see as the location: c:\x\a.txt to c:\some\other\a.txt
For the file system both is just the change of the name of a pointer to the physical data, nothing else.

Posted: **27 Jul 2011 00:23**

about all these semi-pointers - i'm glad i never use that 'cause i'd lose many info

as for all other: i did know that(more or less, so thanks for more

), but i was talking about these operations as they are seen by a mere user.
it seems i got those few posts above a bit wrong, 'cause if it' all about "rename on name collusion even if while Move"(as nas8e9 wrote), then i agree. but if it's not, i still don't get it

Posted: **06 Sep 2011 09:40**

OK, I'll be adding file moves to Custom Copy now (you might call it "Custom Move" but I try to avoid this, see below). After re-reading this thread and a bit of meditation I think we just need one additional check box in Configuration | File Operations:

Use Custom Copy for all move operations

(I know that using the term "Custom Copy" for move operations will strike some as nonsense, but what would be a better solution? It reflects that internally both operations use the same code with only little differences, that both share the mostly same configuration options and interface, and it makes talking about it much more comfortable. I really don't want to end up having to write "Custom Copy/Custom Move" all the time...)

Intra/Cross: The differences between intra and cross volume moves don't have to be taken to the user level IMO. XY will handle this silently and with all necessary respect. I don't see any use for configurability here (having the one done by Custom Copy, and the other by the Shell).

Moved Folders: Once somebody wished for a files-only-move (where the emptied source folders would remain in place). That would be a possible further option (Leave source folders in place), but I'm not sure how often this functionality would actually be used. It might be an overkill. Anybody interested?

Posted: **06 Sep 2011 09:49**

This sounds good to me. A new Custom copy/move checkbox would indeed fix this for users in a simple and clear way.

Posted: **06 Sep 2011 10:51**

admin wrote:I think we just need one additional check box in Configuration | File Operations:
Use Custom Copy for all move operations

agreed

admin wrote:I know that using the term "Custom Copy" for move operations will strike some as nonsense, but what would be a better solution?

why nonsense?! people use TeraCopy understanding that it makes moves as well -and no confusion.

admin wrote:Intra/Cross: The differences between intra and cross volume moves don't have to be taken to the user level IMO. XY will handle this silently and with all necessary respect.

good decision.

admin wrote:Moved Folders: Once somebody wished for a files-only-move (where the emptied source folders would remain in place). Anybody interested?

me have no use in it. or at least i don't have enough fantasy at the moment to imagining for what it could be useful.

Posted: **06 Sep 2011 11:53**

Hmm, I'm just asking myself if we really need the distinction:
Use Custom Copy for all copy operations
Use Custom Copy for all move operations

Would somebody really use a mixed choice? Or should we simply do:
Use Custom Copy for all copy and move operations

Posted: **06 Sep 2011 11:58**

I would keep both checkboxes. If there is even 1 user out there depending on the current behaviour it will cause grief for them.

Posted: **06 Sep 2011 12:03**

iycgtptyarvg wrote:I would keep both checkboxes. If there is even 1 user out there depending on the current behaviour it will cause grief for them.

Yep, good point. The other point is that I haved already implemented it now with 2 checkboxes.

Well actually I made 3 checkboxes because it deemed me more practical:

Code: Select all

[x] Use Custom Copy
    [x] For all copy operations
    [x] For all move operations

Posted: **06 Sep 2011 12:24**

Will the new custom move make these two windows dispensable?

: Unbenannt.png (42.41 KiB) Viewed 2085 times

and:

: Unbenannt2.png (19.38 KiB) Viewed 2084 times

XYplorer Beta Club

Custom Move

Re: Custom copy doesn't work with drag'n'drop

Re: Custom copy doesn't work with drag'n'drop

Re: Custom copy doesn't work with drag'n'drop

Re: Custom copy doesn't work with drag'n'drop

Re: Custom copy doesn't work with drag'n'drop

Re: Custom copy doesn't work with drag'n'drop

Re: Custom copy doesn't work with drag'n'drop

Re: Custom copy doesn't work with drag'n'drop

Custom Move

Re: Custom Move

Re: Custom Move

Re: Custom Move

Re: Custom Move

Re: Custom Move

Re: Custom Move