[tahoe-dev] [tahoe-lafs] #771: tahoe ls doesn't work on files

[tahoe-lafs]

#771: tahoe ls doesn't work on files
---------------------+------------------------------------------------------
 Reporter:  kevan    |           Owner:  nobody   
     Type:  defect   |          Status:  new      
 Priority:  major    |       Milestone:  undecided
Component:  unknown  |         Version:  1.4.1    
 Keywords:           |   Launchpad_bug:           
---------------------+------------------------------------------------------
 If I have an immutable file {{{file2}}} at {{{testdir/file2}}} on my
 remote filesystem, and do {{{tahoe ls testdir/file2}}}, I get

 {{{
 Traceback (most recent call last):
   File "/Users/kacarstensen/Documents/code/tahoe/support/bin/tahoe", line
 8, in <module>
     load_entry_point('allmydata-tahoe==1.4.1-r4026', 'console_scripts',
 'tahoe')()
   File
 "/Users/kacarstensen/Documents/code/tahoe/src/allmydata/scripts/runner.py",
 line 91, in run
     rc = runner(sys.argv[1:])
   File
 "/Users/kacarstensen/Documents/code/tahoe/src/allmydata/scripts/runner.py",
 line 78, in runner
     rc = cli.dispatch[command](so)
   File
 "/Users/kacarstensen/Documents/code/tahoe/src/allmydata/scripts/cli.py",
 line 412, in list
     rc = tahoe_ls.list(options)
   File
 "/Users/kacarstensen/Documents/code/tahoe/src/allmydata/scripts/tahoe_ls.py",
 line 70, in list
     childtype = child[0]
 KeyError: 0
 }}}

 If I do {{{tahoe ls --json testdir/file2}}}, I get

 {{{
 [
  "filenode",
  {
   "mutable": false,
   "ro_uri": "URI:LIT:a_ro_cap",
   "size": 13
  }
 ]
 }}}

 If I do {{{tahoe ls --json testdir/}}}, I get

 {{{
 [
  "dirnode",
  {
   "rw_uri": "URI:DIR2:rw_cap",
   "verify_uri": "URI:DIR2-Verifier:verify_cap",
   "ro_uri": "URI:DIR2-RO:ro_cap",
   "children": {
    "dir2": [
     "dirnode",
     {
      "mutable": true,
      "verify_uri": "URI:DIR2-Verifier:verify_cap",
      "rw_uri": "URI:DIR2:rw_cap",
      "ro_uri": "URI:DIR2-RO:ro_cap",
      "metadata": {
       "ctime": 1248055314.2892411,
       "tahoe": {
        "linkmotime": 1248055314.2892411,
        "linkcrtime": 1248055314.2892411
       },
       "mtime": 1248055314.2892411
      }
     }
    ],
    "test.pdf": [
     "filenode",
     {
      "mutable": false,
      "verify_uri": "URI:CHK-Verifier:verify_cap",
      "metadata": {
       "ctime": 1246685054.166369,
       "tahoe": {
        "linkmotime": 1246685054.166369,
        "linkcrtime": 1246685054.166369
       },
       "mtime": 1246685054.166369
      },
      "ro_uri": "URI:CHK:ro_cap",
      "size": 700145
     }
    ],
    "file2": [
     "filenode",
     {
      "mutable": false,
      "metadata": {
       "ctime": 1247192345.969193,
       "tahoe": {
        "linkmotime": 1247192345.969193,
        "linkcrtime": 1247192345.969193
       },
       "mtime": 1247192345.969193
      },
      "ro_uri": "URI:LIT:ro_cap",
      "size": 13
     }
    ]
   },
   "mutable": true
  }
 ]
 }}}

 If I do {{{tahoe ls testdir/}}}, it works as normal.

 I think the problem is that we haven't correctly implemented parsing for
 {{{GET}}}ing a filecap. Instead of doing, as in
 source:/src/allmydata/scripts/tahoe_ls.py#L55,
 {{{
     children = {childname: d}
 }}}

 thus losing the {{{child[0]}}} item that the loop is looking for, we
 should do something like

 {{{
     children = {childname: [nodetype, d]}
 }}}

 Unfortunately, this too fails because the loop wants to find metadata that
 isn't there.

 I think the best solution here would be (one way or another) to follow
 source:/docs/frontends/webapi.txt#L402 -- that is, to {{{GET}}} the file's
 information using the containing directory's dircap, rather than the
 filecap of the file. That way, we have the metadata that we want for,
 e.g., {{{tahoe ls -l}}}. I'm just kind of stuck on the best way to do
 that.

 The most workable idea I've come up with is to check the results from the
 first {{{GET}}}, and, if they're for a {{{filenode}}} without metadata,
 attempt to re-fetch them by using {{{get_alias}}} on the parent directory
 (which we could infer by parsing the {{{where}}} option. This seems kind
 of roundabout, though -- it seems like it'd be easier to determine, before
 the initial {{{GET}}}, whether the rootcap returned from {{{get_alias}}}
 corresponded to a directory or a file, and do that check there. I'm just
 not sure if there's an easy way to do that, hence this long-winded
 explanation. If there's a more obvious way, I'm open to that, too.

 I'm attaching a patch with a test that demonstrates this bug.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/771>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid