Can't Move To

[jacky]

So a question to verify: will the shell notify me about "not moved items"?

To be clear, XY sends the move request to Windows.

Windows doesn't care that you're trying to move folders such as Recycled or such, and it will do whatever you ask. Unless, for some reason, it can't. This usually means one item is locked (by the system or another app) and as a result cannot be moved (or deleted, etc)

When this occurs, normal Windows behavior occurs : pop up a message to tell the user that an error occured, and everything stops there. Some items were moved, others were not because the operation stopped before it got to them.
Yes, in other words : it's a mess. That's how MS likes it

I don't believe in the idea of a custom list of items not to move, but maybe a way to have XY check each items (so recursively) to make sure there's not locked, and then - just like with Delete (Skip Locked) - ask the user what to do : continue skipping locked items if any, or cancel, could be a good thing.

[admin]

Sorry - there seems to be some misunderstanding between you and me. So a question to verify: will the shell notify me about "not moved items"? If it does, that would be the minimum of info I would expect. But I'm afraid: if it would, it would do it once for each not-moved item? (That is: a lot of MsgBoxes = interrupts?)
But: if there is no better solution (i.e. a list): I would prefer these interrupts for illegal requested moves (!!!) (that's what they are!) instead of not noticing of them.
In another thread about DP you talked about users always wanting to verify what they do. But if I move something, expecting it to be at some new location and to be deleted at the old, but cannot be sure that it happens as requested, I always must compare what I requested with what was done, or must accept possible corruption or loss of data...

For making a list you think of those "items that XY thinks are unmoveble". I would not really like it - as this would be info by guessing. That would not be worth the cost of coding. Either you have a chance to test for "movability" - or it's not ok.

There is no safe test I know of apart from trying to move and see what happens (same for delete and rename).

What items are you thinking about anyway? What specific item should not be moved without a warning?

[PeterH]

You say: move is abended at first not movable item, with InfoBox, but without possibility to select "scip and continue"? Quite bad...

For the rest I think,jackie would want to be tested as much as possible *before* moving, to reduce the chance of not-moved items? Hard to say, if it's woth the cost...

[jacky]

You say: move is abended at first not movable item, with InfoBox, but without possibility to select "scip and continue"? Quite bad...

That's how Windows does it, every time. Just like it does check that there's enough space in the destination, instead it will fail & stop half-way through!

For the rest I think,jackie would want to be tested as much as possible *before* moving, to reduce the chance of not-moved items? Hard to say, if it's woth the cost...

Well, for Don I would think it might not take that much, as he probably can reuse the function for "Delete (Skip Locked)", I would assume it's the exact same test required here.
As for the user, it may need some time but it may also prevent a mess and therefore be worth it. You can test it now, time-wise : select what you want to move, and chose "File|Delete (Skip Locked)" XY will then look for locked items and let you know how many were found. Of course, cancel it then or else they all get removed!

What I would envison is a new option (checkbox) "Skip Locked" on Move To dialog, that would when we press "Ok" trigger such a test, then asking us whether to continue with all unlocked items or cancel it. That way, we can still fully use the Move To feature, but also make sure no locked items will screw it up.
(UDC|Move To could even see this as an option)

[PeterH]

OK - what jacky says makes sense to me.
But *I* would never ever test movability by calling a dialog for deleting And for the space-problem: if it's not tested before, it would make no sense to skip one item and try the next instead, but it would for move, when origin is not movable. I'd not compare this.
So now it's Don's turn to say, if it's possible with not too much cost.

[admin]

Little misunderstanding here. I was just talking about items that cannot or should not be moved for general reasons, now you are talking about locked items and space -- these are specific reasons. Totally different story. As jacky said, this is part of a native handling of file operations.

Wait for the next version, and enjoy the new freedom you get.

[graham]

admin wrote:

Security is okay, but there's a limit. No software will protect you from permanently deleting your only copy of your password collection. So why should software protect from doing a move when you click "move"? If the items really cannot be moved, nothing will happen, if it's dangerous to move them for common reasons, you'll be prompted since I pass all moves through the shell and the shell takes care of such things.

This seems more than adequate bearing in mind the complexities of alternative individual file checking. The one thing that should exist is consistency of the move op regardless of how it is instigated and this is not so at the moment. I am of the opinion that if one is using a file manager with settings to allow see/select 'dangerous' files then the user has to accept responsibility for starting an action as long as the normal prompts exist. The advent of undo presumably will come to the rescue. This makes another assumption that any deleted or overwritten files are recoverable.

Mistakes will happen - accept users have to be sensible if playing with 'dangerous' files.