XYplorer Beta Club

Muchas gracias!

Another configuration request for custom move: I often move small informational text files across volumes that accompany the much larger media files. For the big media files, I always want the byte verification and full custom move operation. But with the smaller text files, I don't need to see the final popup - in fact, I really don't need the custom move behavior at all. But I'm always moving the informational files as a separate step and don't want to have to keep toggling the custom move switch on/off.

Therefore, what would be helpful is to specify a size threshold, in bytes, below which the custom move would not be performed, or at least for not showing the final popup.

What I would like to see -- and this is something that copying side of things would benefit from too -- is an ability to manually trigger queued jobs out of order. Doing one at a time does not provide enough flexibility whereas not having a queue would be too chaotic. I am often in a situation where I reshuffle data amongst my external HDDs and want to move files between internal ones too. There is little performance hit and currently I have to resort to launching Explorer. Right-clicking a job in a queue and selecting "Start" would be so much more convenient and easier.

zer0 wrote:What I would like to see -- and this is something that copying side of things would benefit from too -- is an ability to manually trigger queued jobs out of order. Doing one at a time does not provide enough flexibility whereas not having a queue would be too chaotic. I am often in a situation where I reshuffle data amongst my external HDDs and want to move files between internal ones too. There is little performance hit and currently I have to resort to launching Explorer. Right-clicking a job in a queue and selecting "Start" would be so much more convenient and easier.

Don has previously indicated that he'll consider something called target intelligence or an intelligent queue which will automatically start a parallel job based on criteria like internal vs. external HD and current read and/or write utilisation. I don't think the idea was already fleshed out and I'm not sure whether/where it is on his to-do list.

nas8e9 wrote:

zer0 wrote:What I would like to see -- and this is something that copying side of things would benefit from too -- is an ability to manually trigger queued jobs out of order. Doing one at a time does not provide enough flexibility whereas not having a queue would be too chaotic. I am often in a situation where I reshuffle data amongst my external HDDs and want to move files between internal ones too. There is little performance hit and currently I have to resort to launching Explorer. Right-clicking a job in a queue and selecting "Start" would be so much more convenient and easier.

Don has previously indicated that he'll consider something called target intelligence or an intelligent queue which will automatically start a parallel job based on criteria like internal vs. external HD and current read and/or write utilisation. I don't think the idea was already fleshed out and I'm not sure whether/where it is on his to-do list.

Rule-based intelligence is beyond what I am asking for -- though that could be a natural next step -- just simple click and launch would suffice for the time being.

Another thing that I hope would make sense is for XYcopy to check whether there is enough space in the destination to copy the files. Just tried to copy a bunch and was only told that right at the end. A simple pop-up saying so before starting the process would be sufficient.

zer0 wrote:Another thing that I hope would make sense is for XYcopy to check whether there is enough space in the destination to copy the files. Just tried to copy a bunch and was only told that right at the end. A simple pop-up saying so before starting the process would be sufficient.

Surprising. Free space is checked before copying ever since.

Can you give some details about the situation where it does not seem to work.

admin wrote:Can you give some details about the situation where it does not seem to work.

Sure. I was copying from an internal HDD to an external one via DnD from a tab in one pane to an open tab in another. Worth noting that it was a bunch of files, some got copied, but one didn't. It got to 99% and was stuck there -- I had the window backgrounded -- so I checked and voilà. Do you require any other information?

zer0 wrote:

admin wrote:Can you give some details about the situation where it does not seem to work.

Sure. I was copying from an internal HDD to an external one via DnD from a tab in one pane to an open tab in another. Worth noting that it was a bunch of files, some got copied, but one didn't. It got to 99% and was stuck there -- I had the window backgrounded -- so I checked and voilà. Do you require any other information?

OK, I just rechecked the source code and indeed when overwriting may happen in the job, then available space is calculated per file, not for the whole job in advance. I assume this was the case in your case.

It would be quite time consuming to calculate the available space when overwriting may happen, and impossible when overwriting may happen on a per-file basis (setting "Ask" on name collision). I don't see a good way to handle this ATM.

admin wrote:OK, I just rechecked the source code and indeed when overwriting may happen in the job, then available space is calculated per file, not for the whole job in advance. I assume this was the case in your case.

There is no overwriting going on -- as in, collisions of file names and I am prompted to decide -- there is just some empty space on destination drive and I attempt to copy files to it.

zer0 wrote:

admin wrote:OK, I just rechecked the source code and indeed when overwriting may happen in the job, then available space is calculated per file, not for the whole job in advance. I assume this was the case in your case.

There is no overwriting going on -- as in, collisions of file names and I am prompted to decide -- there is just some empty space on destination drive and I attempt to copy files to it.

What's your "On name collisions" setting?

admin wrote:

zer0 wrote:

admin wrote:OK, I just rechecked the source code and indeed when overwriting may happen in the job, then available space is calculated per file, not for the whole job in advance. I assume this was the case in your case.

There is no overwriting going on -- as in, collisions of file names and I am prompted to decide -- there is just some empty space on destination drive and I attempt to copy files to it.

What's your "On name collisions" setting?

Overwrite if newer.

zer0 wrote:

admin wrote:

zer0 wrote:

admin wrote:OK, I just rechecked the source code and indeed when overwriting may happen in the job, then available space is calculated per file, not for the whole job in advance. I assume this was the case in your case.

There is no overwriting going on -- as in, collisions of file names and I am prompted to decide -- there is just some empty space on destination drive and I attempt to copy files to it.

What's your "On name collisions" setting?

Overwrite if newer.

So Overwrite *could* happen, under conditions that are not previsible at that moment. Therefore no space check avant le job is possible.

admin wrote:Therefore no space check avant le job is possible.

I could be oversimplifying it, but you know the total size of files to be copied and you know (or can find out) the amount of free space on the destination drive. So compare those 2, if space < data size to be copied, pop up a window. Is there a catch I am missing?

P.S. Explorer warns me beforehand, so it is the expected behaviour.

zer0 wrote:

admin wrote:Therefore no space check avant le job is possible.

I could be oversimplifying it, but you know the total size of files to be copied and you know (or can find out) the amount of free space on the destination drive. So compare those 2, if space < data size to be copied, pop up a window. Is there a catch I am missing?

P.S. Explorer warns me beforehand, so it is the expected behaviour.

Sure, but the point is: If overwriting happens the warning could be a false positive.