id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
771	tahoe ls doesn't work on files	kevan	nobody	"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."	defect	closed	major	1.6.0	code-frontend-cli	1.4.1	fixed	tahoe-ls