[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2329: cp -r stops with an exception

[Tahoe-LAFS]

#2329: cp -r stops with an exception
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  warner
         Type:  defect   |     Status:  assigned
     Priority:  major    |  Milestone:  1.10.1
    Component:  code-    |    Version:  1.10.0
  frontend-cli           |   Keywords:  regression tahoe-cp review-needed
   Resolution:           |  release-blocker
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by zooko):

 Replying to [comment:38 warner]:
 >
 > Looking at the table, with an eye towards writing docs that explain what
 has changed, the new "cp -r PARENTCAP/dir local/missing" case (F2, bottom
 row) stands out. It's consistent with current trunk, but not with 1.10, or
 the proposed behavior for other directory-like sources, or with bin/cp.
 It'd be easier to explain if it were `local/missing/file` instead. I'm
 sure we've discussed this to death..

 Let's see…

 That is intentional in the comment:27 algorithm. The reasoning is twofold:

 First of all, the question of whether you want the bag vs. the contents of
 the bag is determined by whether the directory-like source has a name (the
 `F` column) vs. doesn't have a name (the `G` and `H` columns). That's a
 nice simple rule, and according to that, the result in the "comment:27 -r"
 row has to be `local/missing/dir/file` instead of `local/missing/file`,
 because the latter would be just the contents of the bag (`file`) instead
 of the bag (`dir/file`).

 So looking at [comment:35 the table], the cells of column `F` need to
 result in /dir/file` (if they aren't instead an error) and the cells of
 columns `G` and `H` need to result in `file` (if they aren't instead an
 error).

 Second, the comment:27 algorithm behaves the same way whether the target
 exists or doesn't exist at the beginning of the algorithm. This is (in my
 intuition) a nice simple rule, and it also means there isn't a race
 condition in which the behavior is unpredictable because the existence of
 the target is unpredictable.

 So looking at the table, that means the result of `F1` and `F2` both need
 to result in the same behavior as each other.

 I'm not saying this rationale is better than other rationales that would
 justify other designs (such as "this is as much like `/bin/cp` as we could
 make it), but that's the rationale for this design.

 > * try to make the code implement the table

 Yay!

 > * put an edited form of the table into NEWS, to explain the user-visible
 change

 Yay!

 > * put a smaller form (just bin/cp and current behavior) into cli.rst

 Yay!

 > * put an even smaller form (just current behavior, maybe as prose) into
 the tahoe-cp `--help` docstring

 Yay!


 ☺

 Thank you for your good work on this.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2329#comment:39>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage