source: trunk/docs/frontends/CLI.rst

Last change on this file was 78a13aa, checked in by meejah <meejah@…>, at 2019-06-14T04:19:28Z

cryptography back into docs

  • Property mode set to 100644
File size: 24.2 KB
Line 
1.. -*- coding: utf-8-with-signature -*-
2
3===========================
4The Tahoe-LAFS CLI commands
5===========================
6
71.  `Overview`_
82.  `CLI Command Overview`_
9
10    1.  `Unicode Support`_
11
123.  `Node Management`_
134.  `File Store Manipulation`_
14
15    1.  `Starting Directories`_
16    2.  `Command Syntax Summary`_
17    3.  `Command Examples`_
18
195.  `Storage Grid Maintenance`_
206.  `Debugging`_
21
22
23Overview
24========
25
26Tahoe-LAFS provides a single executable named "``tahoe``", which can be used
27to create and manage client/server nodes, manipulate the file store, and
28perform several debugging/maintenance tasks. This executable is installed
29into your virtualenv when you run ``pip install tahoe-lafs``.
30
31
32CLI Command Overview
33====================
34
35The "``tahoe``" tool provides access to three categories of commands.
36
37* node management: create a client/server node, start/stop/restart it
38* file store manipulation: list files, upload, download, unlink, rename
39* debugging: unpack cap-strings, examine share files
40
41To get a list of all commands, just run "``tahoe``" with no additional
42arguments. "``tahoe --help``" might also provide something useful.
43
44Running "``tahoe --version``" will display a list of version strings, starting
45with the "allmydata" module (which contains the majority of the Tahoe-LAFS
46functionality) and including versions for a number of dependent libraries,
47like Twisted, Foolscap, cryptography, and zfec. "``tahoe --version-and-path``"
48will also show the path from which each library was imported.
49
50On Unix systems, the shell expands filename wildcards (``'*'`` and ``'?'``)
51before the program is able to read them, which may produce unexpected results
52for many ``tahoe`` comands. We recommend, if you use wildcards, to start the
53path with "``./``", for example "``tahoe cp -r ./* somewhere:``". This
54prevents the expanded filename from being interpreted as an option or as an
55alias, allowing filenames that start with a dash or contain colons to be
56handled correctly.
57
58On Windows, a single letter followed by a colon is treated as a drive
59specification rather than an alias (and is invalid unless a local path is
60allowed in that context). Wildcards cannot be used to specify multiple
61filenames to ``tahoe`` on Windows.
62
63Unicode Support
64---------------
65
66As of Tahoe-LAFS v1.7.0 (v1.8.0 on Windows), the ``tahoe`` tool supports
67non-ASCII characters in command lines and output. On Unix, the command-line
68arguments are assumed to use the character encoding specified by the
69current locale (usually given by the ``LANG`` environment variable).
70
71If a name to be output contains control characters or characters that
72cannot be represented in the encoding used on your terminal, it will be
73quoted. The quoting scheme used is similar to `POSIX shell quoting`_: in
74a "double-quoted" string, backslashes introduce escape sequences (like
75those in Python strings), but in a 'single-quoted' string all characters
76stand for themselves. This quoting is only used for output, on all
77operating systems. Your shell interprets any quoting or escapes used on
78the command line.
79
80.. _`POSIX shell quoting`: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
81
82
83Node Management
84===============
85
86"``tahoe create-node [NODEDIR]``" is the basic make-a-new-node
87command. It creates a new directory and populates it with files that
88will allow the "``tahoe start``" and related commands to use it later
89on. ``tahoe create-node`` creates nodes that have client functionality
90(upload/download files), web API services (controlled by the
91'[node]web.port' configuration), and storage services (unless
92``--no-storage`` is specified).
93
94NODEDIR defaults to ``~/.tahoe/`` , and newly-created nodes default to
95publishing a web server on port 3456 (limited to the loopback interface, at
96127.0.0.1, to restrict access to other programs on the same host). All of the
97other "``tahoe``" subcommands use corresponding defaults (with the exception
98that "``tahoe run``" defaults to running a node in the current directory).
99
100"``tahoe create-client [NODEDIR]``" creates a node with no storage service.
101That is, it behaves like "``tahoe create-node --no-storage [NODEDIR]``".
102(This is a change from versions prior to v1.6.0.)
103
104"``tahoe create-introducer [NODEDIR]``" is used to create the Introducer node.
105This node provides introduction services and nothing else. When started, this
106node will produce a ``private/introducer.furl`` file, which should be
107published to all clients.
108
109
110Running Nodes
111-------------
112
113No matter what kind of node you created, the correct way to run it is
114to use the ``tahoe run`` command. "``tahoe run [NODEDIR]``" will start
115a previously-created node in the foreground. This command functions
116the same way on all platforms and logs to stdout. If you want to run
117the process as a daemon, it is recommended that you use your favourite
118daemonization tool.
119
120The now-deprecated "``tahoe start [NODEDIR]``" command will launch a
121previously-created node. It will launch the node into the background
122using ``tahoe daemonize`` (and internal-only command, not for user
123use). On some platforms (including Windows) this command is unable to
124run a daemon in the background; in that case it behaves in the same
125way as "``tahoe run``". ``tahoe start`` also monitors the logs for up
126to 5 seconds looking for either a succesful startup message or for
127early failure messages and produces an appropriate exit code.  You are
128encouraged to use ``tahoe run`` along with your favourite
129daemonization tool instead of this. ``tahoe start`` is maintained for
130backwards compatibility of users already using it; new scripts should
131depend on ``tahoe run``.
132
133"``tahoe stop [NODEDIR]``" will shut down a running node. "``tahoe
134restart [NODEDIR]``" will stop and then restart a running
135node. Similar to above, you should use ``tahoe run`` instead alongside
136your favourite daemonization tool.
137
138
139File Store Manipulation
140=======================
141
142These commands let you exmaine a Tahoe-LAFS file store, providing basic
143list/upload/download/unlink/rename/mkdir functionality. They can be used as
144primitives by other scripts. Most of these commands are fairly thin wrappers
145around web-API calls, which are described in :doc:`webapi`.
146
147By default, all file store manipulation commands look in ``~/.tahoe/`` to
148figure out which Tahoe-LAFS node they should use. When the CLI command makes
149web-API calls, it will use ``~/.tahoe/node.url`` for this purpose: a running
150Tahoe-LAFS node that provides a web-API port will write its URL into this
151file. If you want to use a node on some other host, just create ``~/.tahoe/``
152and copy that node's web-API URL into this file, and the CLI commands will
153contact that node instead of a local one.
154
155These commands also use a table of "aliases" to figure out which directory
156they ought to use a starting point. This is explained in more detail below.
157
158Starting Directories
159--------------------
160
161As described in :doc:`../architecture`, the Tahoe-LAFS distributed file store
162consists of a collection of directories and files, each of which has a
163"read-cap" or a "write-cap" (also known as a URI). Each directory is simply a
164table that maps a name to a child file or directory, and this table is turned
165into a string and stored in a mutable file. The whole set of directory and
166file "nodes" are connected together into a directed graph.
167
168To use this collection of files and directories, you need to choose a
169starting point: some specific directory that we will refer to as a
170"starting directory".  For a given starting directory, the
171"``ls [STARTING_DIR]``" command would list the contents of this directory,
172the "``ls [STARTING_DIR]/dir1``" command would look inside this directory
173for a child named "``dir1``" and list its contents,
174"``ls [STARTING_DIR]/dir1/subdir2``" would look two levels deep, etc.
175
176Note that there is no real global "root" directory, but instead each
177starting directory provides a different, possibly overlapping
178perspective on the graph of files and directories.
179
180Each Tahoe-LAFS node remembers a list of starting points, called "aliases",
181which are short Unicode strings that stand in for a directory read- or
182write- cap. They are stored (encoded as UTF-8) in the file
183``NODEDIR/private/aliases`` .  If you use the command line "``tahoe ls``"
184without any "[STARTING_DIR]" argument, then it will use the default alias,
185which is ``tahoe:``, therefore "``tahoe ls``" has the same effect as
186"``tahoe ls tahoe:``".  The same goes for the other commands that can
187reasonably use a default alias: ``get``, ``put``, ``mkdir``, ``mv``, and
188``rm``.
189
190For backwards compatibility with Tahoe-LAFS v1.0, if the ``tahoe:`` alias
191is not found in ``~/.tahoe/private/aliases``, the CLI will use the contents
192of ``~/.tahoe/private/root_dir.cap`` instead. Tahoe-LAFS v1.0 had only a
193single starting point, and stored it in this ``root_dir.cap`` file, so v1.1
194and later will use it if necessary. However, once you've set a ``tahoe:``
195alias with "``tahoe set-alias``", that will override anything in the old
196``root_dir.cap`` file.
197
198The Tahoe-LAFS CLI commands use a similar path syntax to ``scp`` and
199``rsync`` -- an optional ``ALIAS:`` prefix, followed by the pathname or
200filename. Some commands (like "``tahoe cp``") use the lack of an alias to
201mean that you want to refer to a local file, instead of something from the
202Tahoe-LAFS file store. Another way to indicate this is to start the
203pathname with "./", "~/", "~username/", or "/". On Windows, aliases
204cannot be a single character, so that it is possible to distinguish a
205path relative to an alias from a path starting with a local drive specifier.
206
207When you're dealing a single starting directory, the ``tahoe:`` alias is
208all you need. But when you want to refer to something that isn't yet
209attached to the graph rooted at that starting directory, you need to
210refer to it by its capability. The way to do that is either to use its
211capability directory as an argument on the command line, or to add an
212alias to it, with the "``tahoe add-alias``" command. Once you've added an
213alias, you can use that alias as an argument to commands.
214
215The best way to get started with Tahoe-LAFS is to create a node, start it,
216then use the following command to create a new directory and set it as your
217``tahoe:`` alias::
218
219 tahoe create-alias tahoe
220
221After that you can use "``tahoe ls tahoe:``" and
222"``tahoe cp local.txt tahoe:``", and both will refer to the directory that
223you've just created.
224
225SECURITY NOTE: For users of shared systems
226``````````````````````````````````````````
227
228Another way to achieve the same effect as the above "``tahoe create-alias``"
229command is::
230
231 tahoe add-alias tahoe `tahoe mkdir`
232
233However, command-line arguments are visible to other users (through the
234``ps`` command or ``/proc`` filesystem, or the Windows Process Explorer tool),
235so if you are using a Tahoe-LAFS node on a shared host, your login neighbors
236will be able to see (and capture) any directory caps that you set up with the
237"``tahoe add-alias``" command.
238
239The "``tahoe create-alias``" command avoids this problem by creating a new
240directory and putting the cap into your aliases file for you. Alternatively,
241you can edit the ``NODEDIR/private/aliases`` file directly, by adding a line
242like this::
243
244 fun: URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
245
246By entering the dircap through the editor, the command-line arguments are
247bypassed, and other users will not be able to see them. Once you've added the
248alias, no other secrets are passed through the command line, so this
249vulnerability becomes less significant: they can still see your filenames and
250other arguments you type there, but not the caps that Tahoe-LAFS uses to permit
251access to your files and directories.
252
253
254Command Syntax Summary
255----------------------
256
257``tahoe add-alias ALIAS[:] DIRCAP``
258
259``tahoe create-alias ALIAS[:]``
260
261``tahoe list-aliases``
262
263``tahoe mkdir``
264
265``tahoe mkdir PATH``
266
267``tahoe ls [PATH]``
268
269``tahoe webopen [PATH]``
270
271``tahoe put [--mutable] [FROMLOCAL|-]``
272
273``tahoe put [--mutable] FROMLOCAL|- TOPATH``
274
275``tahoe put [FROMLOCAL|-] mutable-file-writecap``
276
277``tahoe get FROMPATH [TOLOCAL|-]``
278
279``tahoe cp [-r] FROMPATH TOPATH``
280
281``tahoe rm PATH``
282
283``tahoe mv FROMPATH TOPATH``
284
285``tahoe ln FROMPATH TOPATH``
286
287``tahoe backup FROMLOCAL TOPATH``
288
289In these summaries, ``PATH``, ``TOPATH`` or ``FROMPATH`` can be one of:
290
291* ``[SUBDIRS/]FILENAME`` for a path relative to the default ``tahoe:`` alias;
292* ``ALIAS:[SUBDIRS/]FILENAME`` for a path relative to another alias;
293* ``DIRCAP/[SUBDIRS/]FILENAME`` or ``DIRCAP:./[SUBDIRS/]FILENAME`` for a path
294  relative to a directory cap.
295
296See `CLI Command Overview`_ above for information on using wildcards with
297local paths, and different treatment of colons between Unix and Windows.
298
299``FROMLOCAL`` or ``TOLOCAL`` is a path in the local filesystem.
300
301
302Command Examples
303----------------
304
305``tahoe add-alias ALIAS[:] DIRCAP``
306
307 An example would be::
308
309  tahoe add-alias fun URI:DIR2:ovjy4yhylqlfoqg2vcze36dhde:4d4f47qko2xm5g7osgo2yyidi5m4muyo2vjjy53q4vjju2u55mfa
310
311 This creates an alias ``fun:`` and configures it to use the given directory
312 cap. Once this is done, "``tahoe ls fun:``" will list the contents of this
313 directory. Use "``tahoe add-alias tahoe DIRCAP``" to set the contents of the
314 default ``tahoe:`` alias.
315
316 Since Tahoe-LAFS v1.8.2, the alias name can be given with or without the
317 trailing colon.
318
319 On Windows, the alias should not be a single character, because it would be
320 confused with the drive letter of a local path.
321
322``tahoe create-alias fun``
323
324 This combines "``tahoe mkdir``" and "``tahoe add-alias``" into a single step.
325
326``tahoe list-aliases``
327
328 This displays a table of all configured aliases.
329
330``tahoe mkdir``
331
332 This creates a new empty unlinked directory, and prints its write-cap to
333 stdout. The new directory is not attached to anything else.
334
335``tahoe mkdir subdir``
336
337``tahoe mkdir /subdir``
338
339 This creates a new empty directory and attaches it below the root directory
340 of the default ``tahoe:`` alias with the name "``subdir``".
341
342``tahoe ls``
343
344``tahoe ls /``
345
346``tahoe ls tahoe:``
347
348``tahoe ls tahoe:/``
349
350 All four list the root directory of the default ``tahoe:`` alias.
351
352``tahoe ls subdir``
353
354 This lists a subdirectory of your file store.
355
356``tahoe webopen``
357
358``tahoe webopen tahoe:``
359
360``tahoe webopen tahoe:subdir/``
361
362``tahoe webopen subdir/``
363
364 This uses the python 'webbrowser' module to cause a local web browser to
365 open to the web page for the given directory. This page offers interfaces to
366 add, download, rename, and unlink files and subdirectories in that directory.
367 If no alias or path is given, this command opens the root directory of the
368 default ``tahoe:`` alias.
369
370``tahoe put file.txt``
371
372``tahoe put ./file.txt``
373
374``tahoe put /tmp/file.txt``
375
376``tahoe put ~/file.txt``
377
378 These upload the local file into the grid, and prints the new read-cap to
379 stdout. The uploaded file is not attached to any directory. All one-argument
380 forms of "``tahoe put``" perform an unlinked upload.
381
382``tahoe put -``
383
384``tahoe put``
385
386 These also perform an unlinked upload, but the data to be uploaded is taken
387 from stdin.
388
389``tahoe put file.txt uploaded.txt``
390
391``tahoe put file.txt tahoe:uploaded.txt``
392
393 These upload the local file and add it to your ``tahoe:`` root with the name
394 "``uploaded.txt``".
395
396``tahoe put file.txt subdir/foo.txt``
397
398``tahoe put - subdir/foo.txt``
399
400``tahoe put file.txt tahoe:subdir/foo.txt``
401
402``tahoe put file.txt DIRCAP/foo.txt``
403
404``tahoe put file.txt DIRCAP/subdir/foo.txt``
405
406 These upload the named file and attach them to a subdirectory of the given
407 root directory, under the name "``foo.txt``". When a directory write-cap is
408 given, you can use either ``/`` (as shown above) or ``:./`` to separate it
409 from the following path. When the source file is named "``-``", the contents
410 are taken from stdin.
411
412``tahoe put file.txt --mutable``
413
414 Create a new (SDMF) mutable file, fill it with the contents of ``file.txt``,
415 and print the new write-cap to stdout.
416
417``tahoe put file.txt MUTABLE-FILE-WRITECAP``
418
419 Replace the contents of the given mutable file with the contents of
420 ``file.txt`` and print the same write-cap to stdout.
421
422``tahoe cp file.txt tahoe:uploaded.txt``
423
424``tahoe cp file.txt tahoe:``
425
426``tahoe cp file.txt tahoe:/``
427
428``tahoe cp ./file.txt tahoe:``
429
430 These upload the local file and add it to your ``tahoe:`` root with the name
431 "``uploaded.txt``".
432
433``tahoe cp tahoe:uploaded.txt downloaded.txt``
434
435``tahoe cp tahoe:uploaded.txt ./downloaded.txt``
436
437``tahoe cp tahoe:uploaded.txt /tmp/downloaded.txt``
438
439``tahoe cp tahoe:uploaded.txt ~/downloaded.txt``
440
441 This downloads the named file from your ``tahoe:`` root, and puts the result on
442 your local filesystem.
443
444``tahoe cp tahoe:uploaded.txt fun:stuff.txt``
445
446 This copies a file from your ``tahoe:`` root to a different directory, set up
447 earlier with "``tahoe add-alias fun DIRCAP``" or "``tahoe create-alias fun``".
448
449 ``tahoe cp -r ~/my_dir/ tahoe:``
450
451 This copies the folder ``~/my_dir/`` and all its children to the grid, creating
452 the new folder ``tahoe:my_dir``. Note that the trailing slash is not required:
453 all source arguments which are directories will be copied into new
454 subdirectories of the target.
455
456 The behavior of ``tahoe cp``, like the regular UNIX ``/bin/cp``, is subtly
457 different depending upon the exact form of the arguments. In particular:
458
459* Trailing slashes indicate directories, but are not required.
460* If the target object does not already exist:
461  * and if the source is a single file, it will be copied into the target;
462  * otherwise, the target will be created as a directory.
463* If there are multiple sources, the target must be a directory.
464* If the target is a pre-existing file, the source must be a single file.
465* If the target is a directory, each source must be a named file, a named
466  directory, or an unnamed directory. It is not possible to copy an unnamed
467  file (e.g. a raw filecap) into a directory, as there is no way to know what
468  the new file should be named.
469
470
471``tahoe unlink uploaded.txt``
472
473``tahoe unlink tahoe:uploaded.txt``
474
475 This unlinks a file from your ``tahoe:`` root (that is, causes there to no
476 longer be an entry ``uploaded.txt`` in the root directory that points to it).
477 Note that this does not delete the file from the grid.
478 For backward compatibility, ``tahoe rm`` is accepted as a synonym for
479 ``tahoe unlink``.
480
481``tahoe mv uploaded.txt renamed.txt``
482
483``tahoe mv tahoe:uploaded.txt tahoe:renamed.txt``
484
485 These rename a file within your ``tahoe:`` root directory.
486
487``tahoe mv uploaded.txt fun:``
488
489``tahoe mv tahoe:uploaded.txt fun:``
490
491``tahoe mv tahoe:uploaded.txt fun:uploaded.txt``
492
493 These move a file from your ``tahoe:`` root directory to the directory
494 set up earlier with "``tahoe add-alias fun DIRCAP``" or
495 "``tahoe create-alias fun``".
496
497``tahoe backup ~ work:backups``
498
499 This command performs a versioned backup of every file and directory
500 underneath your "``~``" home directory, placing an immutable timestamped
501 snapshot in e.g. ``work:backups/Archives/2009-02-06_04:00:05Z/`` (note that
502 the timestamp is in UTC, hence the "Z" suffix), and a link to the latest
503 snapshot in work:backups/Latest/ . This command uses a small SQLite database
504 known as the "backupdb", stored in ``~/.tahoe/private/backupdb.sqlite``, to
505 remember which local files have been backed up already, and will avoid
506 uploading files that have already been backed up (except occasionally that
507 will randomly upload them again if it has been awhile since had last been
508 uploaded, just to make sure that the copy of it on the server is still good).
509 It compares timestamps and filesizes when making this comparison. It also
510 re-uses existing directories which have identical contents. This lets it
511 run faster and reduces the number of directories created.
512
513 If you reconfigure your client node to switch to a different grid, you
514 should delete the stale backupdb.sqlite file, to force "``tahoe backup``"
515 to upload all files to the new grid.
516
517 The fact that "tahoe backup" checks timestamps on your local files and
518 skips ones that don't appear to have been changed is one of the major
519 differences between "tahoe backup" and "tahoe cp -r". The other major
520 difference is that "tahoe backup" keeps links to all of the versions that
521 have been uploaded to the grid, so you can navigate among old versions
522 stored in the grid. In contrast, "tahoe cp -r" unlinks the previous
523 version from the grid directory and links the new version into place,
524 so unless you have a link to the older version stored somewhere else,
525 you'll never be able to get back to it.
526
527``tahoe backup --exclude=*~ ~ work:backups``
528
529 Same as above, but this time the backup process will ignore any
530 filename that will end with '~'. ``--exclude`` will accept any standard
531 Unix shell-style wildcards, as implemented by the
532 `Python fnmatch module <http://docs.python.org/library/fnmatch.html>`__.
533 You may give multiple ``--exclude`` options.  Please pay attention that
534 the pattern will be matched against any level of the directory tree;
535 it's still impossible to specify absolute path exclusions.
536
537``tahoe backup --exclude-from=/path/to/filename ~ work:backups``
538
539 ``--exclude-from`` is similar to ``--exclude``, but reads exclusion
540 patterns from ``/path/to/filename``, one per line.
541
542``tahoe backup --exclude-vcs ~ work:backups``
543
544 This command will ignore any file or directory name known to be used by
545 version control systems to store metadata. The excluded names are:
546
547  * CVS
548  * RCS
549  * SCCS
550  * .git
551  * .gitignore
552  * .cvsignore
553  * .svn
554  * .arch-ids
555  * {arch}
556  * =RELEASE-ID
557  * =meta-update
558  * =update
559  * .bzr
560  * .bzrignore
561  * .bzrtags
562  * .hg
563  * .hgignore
564  * _darcs
565
566Storage Grid Maintenance
567========================
568
569``tahoe manifest tahoe:``
570
571``tahoe manifest --storage-index tahoe:``
572
573``tahoe manifest --verify-cap tahoe:``
574
575``tahoe manifest --repair-cap tahoe:``
576
577``tahoe manifest --raw tahoe:``
578
579 This performs a recursive walk of the given directory, visiting every file
580 and directory that can be reached from that point. It then emits one line to
581 stdout for each object it encounters.
582
583 The default behavior is to print the access cap string (like ``URI:CHK:..``
584 or ``URI:DIR2:..``), followed by a space, followed by the full path name.
585
586 If ``--storage-index`` is added, each line will instead contain the object's
587 storage index. This (string) value is useful to determine which share files
588 (on the server) are associated with this directory tree. The ``--verify-cap``
589 and ``--repair-cap`` options are similar, but emit a verify-cap and repair-cap,
590 respectively. If ``--raw`` is provided instead, the output will be a
591 JSON-encoded dictionary that includes keys for pathnames, storage index
592 strings, and cap strings. The last line of the ``--raw`` output will be a JSON
593 encoded deep-stats dictionary.
594
595``tahoe stats tahoe:``
596
597 This performs a recursive walk of the given directory, visiting every file
598 and directory that can be reached from that point. It gathers statistics on
599 the sizes of the objects it encounters, and prints a summary to stdout.
600
601
602Debugging
603=========
604
605For a list of all debugging commands, use "``tahoe debug``". For more detailed
606help on any of these commands, use "``tahoe debug COMMAND --help``".
607
608"``tahoe debug find-shares STORAGEINDEX NODEDIRS..``" will look through one or
609more storage nodes for the share files that are providing storage for the
610given storage index.
611
612"``tahoe debug catalog-shares NODEDIRS..``" will look through one or more
613storage nodes and locate every single share they contain. It produces a report
614on stdout with one line per share, describing what kind of share it is, the
615storage index, the size of the file is used for, etc. It may be useful to
616concatenate these reports from all storage hosts and use it to look for
617anomalies.
618
619"``tahoe debug dump-share SHAREFILE``" will take the name of a single share file
620(as found by "``tahoe find-shares``") and print a summary of its contents to
621stdout. This includes a list of leases, summaries of the hash tree, and
622information from the UEB (URI Extension Block). For mutable file shares, it
623will describe which version (seqnum and root-hash) is being stored in this
624share.
625
626"``tahoe debug dump-cap CAP``" will take any Tahoe-LAFS URI and unpack it
627into separate pieces. The most useful aspect of this command is to reveal the
628storage index for any given URI. This can be used to locate the share files
629that are holding the encoded+encrypted data for this file.
630
631"``tahoe debug corrupt-share SHAREFILE``" will flip a bit in the given
632sharefile. This can be used to test the client-side verification/repair code.
633Obviously, this command should not be used during normal operation.
Note: See TracBrowser for help on using the repository browser.