Opened at 2012-06-30T16:02:23Z

Closed at 2013-03-20T19:05:30Z

#1783 closed defect (fixed)

tahoe cp --verbose progress messages show double the actual number of files

Reported by: davidsarah Owned by: davidsarah
Priority: normal Milestone: 1.10.0
Component: code-frontend-cli Version: 1.9.1
Keywords: tahoe-cp Cc:
Launchpad Bug:

Description 

$ ls test
bar  baz  foo
$ bin/tahoe cp --verbose test/* test2:
examining 0 of 5
examining 1 of 5
examining 2 of 5
examining 3 of 5
examining 4 of 5
attaching sources to targets, 3 files / 0 dirs in root
targets assigned, 1 dirs, 6 files
starting copy, 6 files, 1 directories
1/6 files, 0/1 directories
2/6 files, 0/1 directories
3/6 files, 0/1 directories
1/1 directories
Success: files copied

Change History (5)

comment:1 Changed at 2012-06-30T16:03:57Z by davidsarah

  • Owner set to davidsarah
  • Status changed from new to assigned

Thanks to sickness for reporting this.

comment:2 follow-up: Changed at 2012-06-30T16:06:34Z by davidsarah

Another minor issue we can fix at the same time is that the "examining %d of %d" outputs should probably be 1-based rather than 0-based.

comment:3 in reply to: ↑ 2 Changed at 2012-11-22T01:33:45Z by davidsarah

Replying to davidsarah:

Another minor issue we can fix at the same time is that the "examining %d of %d" outputs should probably be 1-based rather than 0-based.

That was #1805, now fixed. I don't think this issue was fixed.

comment:4 Changed at 2013-03-20T01:02:40Z by davidsarah

The problem was that in the loop at git/src/allmydata/scripts/tahoe_cp.py@595d611c#L653, self.files_to_copy is incremented by both attach_to_target and the loop body.

Please review: ​https://github.com/davidsarah/tahoe-lafs/commit/1783-no-double-counting

comment:5 Changed at 2013-03-20T19:05:30Z by warner

  • Resolution set to fixed
  • Status changed from assigned to closed

Looks good, landed in ef0a6c30.

Note: See TracTickets for help on using tickets.