Community
Participate
Working Groups
We don't currently handle the case where your target location for a copy/move is already taken. We need to be smart about this: - copying file X to its own parent should rename the new copy, such as "Copy of X". - copying folder Y to a location that already has folder Y should do the same - if we are picking names then we will want the ability to rename afterward (which can be done with a move) This implies some kind of "middle step" in the file move/copy UI, after we've assembled the targets and before we call the fileClient. The issue is that we may not have all the cached information needed to look for collisions, so we would have to GET the children of the proposed target. There is also some server side smarts here. John mentioned that the server issues special error codes, such as 412 error code for "you said not to overwrite, but there was a resource by that name already" We have to decide where validation occurs.
For M6, I have specified "no-overwrite" in the call to the server. This will just always fail (with 412 error) in the case where copy/move destination is occupied.
Rename is now working (there is an icon in the actions column that pops up an edit box for rename). Leaving bug open to clean up the target proposals.
fixed. I've added more target proposals to the menus, and fixed some bugs where we were proposing invalid targets. For the menu choices, which are supposed to be "common/quick" file restructuring, I am not allowing things like implied rename or implied copy/prompt for rename of files. My reasoning here is we have quick ways to do rename (the rename command) and to do copy/rename (ctrl-c followed by ctrl-v), and I don't want to propose these rename actions as part of the common move/copy targets, where the user doesn't have to think. So what I changed here is: - you can now copy a directory to itself (no reason that you can't copy it inside itself) - you cannot move a directory into itself - we no longer propose move/copy into the existing parent location (that was a bug). Note that we *could* decide that this implies a rename or a copy with rename, but we would have to generate new names or prompt for new ones. The directory prompter can be used when you know you really want to do something tricky. - all children of the breadcrumb location are now proposed as targets (unless they are part of the source selections). So for the common cases, if you can see it on the nav, it's a proposed target.
