#104: does cp -r work as expected?
-----------------------------------+-------------------------------------
Reporter: zooko | Owner: warner
Type: task | Status: closed
Priority: major | Milestone: soon
Component: code-frontend-cli | Version: 0.7.0
Resolution: invalid | Keywords: usability tahoe-cp docs
Launchpad Bug: |
-----------------------------------+-------------------------------------
Changes (by daira):
* status: new => closed
* resolution: => invalid
Old description:
> It would be good if the command-lines
>
> {{{
> allmydata-tahoe get
> }}}
>
> and
>
> {{{
> allmydata-tahoe put
> }}}
>
> supported the {{{--recursive}}} or {{{-r}}} option so that you could
> upload or download and entire collection of files with one command-line.
>
> There are actually a host of issues that arise in implementing this, such
> as those mentioned in the "names versus identifiers" section of
> webapi.txt, and quoted here:
>
> {{{
> For example, suppose you are writing code which recursively downloads the
> contents of a directory. The first thing your code does is fetch the
> listing
> of the contents of the directory. For each child that it fetched, if that
> child is a file then it downloads the file, and if that child is a
> directory
> then it recurses into that directory. Now, if the download and the
> recurse
> actions are performed using the child's name, then the results might be
> wrong, because for example a child name that pointed to a sub-directory
> when
> you listed the directory might have been changed to point to a file, in
> which
> case your attempt to recurse into it would result in an error and the
> file
> would be skipped, or a child name that pointed to a file when you listed
> the
> directory might now point to a sub-directory, in which case your attempt
> to
> download the child would result in a file containing HTML text describing
> the
> sub-directory!
> }}}
>
> These problems can be avoided by traversing identifiers instead of names,
> but the next problems can't. The next problems are that dirnodes can
> recurse (a dirnode can contain an entry pointing to another dirnode which
> contains an entry pointing to the first), or can converge (two entries in
> the same or different dirnodes can point to the same object). We could
> implement a recursive download of such things by (perhaps arbitrarily)
> choosing one path to be a real link and the other to be a symlink. But
> Windows doesn't have symlinks. Another option would be to abort and
> print an error message if such a pattern is encountered.
New description:
It would be good if the command-lines
{{{
allmydata-tahoe get
}}}
and
{{{
allmydata-tahoe put
}}}
supported the {{{--recursive}}} or {{{-r}}} option so that you could
upload or download and entire collection of files with one command-line.
There are actually a host of issues that arise in implementing this, such
as those mentioned in the "names versus identifiers" section of
webapi.txt, and quoted here:
{{{
For example, suppose you are writing code which recursively downloads the
contents of a directory. The first thing your code does is fetch the
listing
of the contents of the directory. For each child that it fetched, if that
child is a file then it downloads the file, and if that child is a
directory
then it recurses into that directory. Now, if the download and the recurse
actions are performed using the child's name, then the results might be
wrong, because for example a child name that pointed to a sub-directory
when
you listed the directory might have been changed to point to a file, in
which
case your attempt to recurse into it would result in an error and the file
would be skipped, or a child name that pointed to a file when you listed
the
directory might now point to a sub-directory, in which case your attempt
to
download the child would result in a file containing HTML text describing
the
sub-directory!
}}}
These problems can be avoided by traversing identifiers instead of names,
but the next problems can't. The next problems are that dirnodes can
recurse (a dirnode can contain an entry pointing to another dirnode which
contains an entry pointing to the first), or can converge (two entries in
the same or different dirnodes can point to the same object). We could
implement a recursive download of such things by (perhaps arbitrarily)
choosing one path to be a real link and the other to be a symlink. But
Windows doesn't have symlinks. Another option would be to abort and print
an error message if such a pattern is encountered.
--
Comment:
Closed for vagueness.
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/104#comment:25>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage