After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 746360 - Wrong output from fsck
Wrong output from fsck
Status: RESOLVED FIXED
Product: ostree
Classification: Infrastructure
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: OSTree maintainer(s)
OSTree maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-03-17 19:49 UTC by Dan Nicholson
Modified: 2015-03-18 13:32 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
fsck: Fix object count output (988 bytes, patch)
2015-03-17 20:11 UTC, Dan Nicholson 		none Details | Review
fsck: Fix object count output (948 bytes, patch)
2015-03-18 00:04 UTC, Dan Nicholson 		none Details | Review

Description Dan Nicholson 2015-03-17 19:49:33 UTC 
fsck prints the current object index starting at 0 and never reaches the
total number of objects.

$ ./ostree --repo=$REPO fsck
Enumerating objects...
Verifying content integrity of 1 commit objects...
0/13 objects
1/13 objects
2/13 objects
3/13 objects
4/13 objects
5/13 objects
6/13 objects
7/13 objects
8/13 objects
9/13 objects
10/13 objects
11/13 objects
12/13 objects
Comment 1 Dan Nicholson 2015-03-17 20:11:12 UTC 
Created attachment 299626 [details] [review]
fsck: Fix object count output

The object count comes from g_hash_table_size(), so it's not 0 based
index. Starting the index at 0 makes the output never reach the total
number of objects.
Comment 2 Matthew Barnes 2015-03-17 21:38:14 UTC 
Comment on attachment 299626 [details] [review]
fsck: Fix object count output

I suggest just changing the g_print() argument to i + 1 so as not to affect the (i % mod == 0) calculation.
Comment 3 Dan Nicholson 2015-03-18 00:04:56 UTC 
Created attachment 299667 [details] [review]
fsck: Fix object count output

The object count comes from g_hash_table_size(), so it's not a 0 based
index. In order to maintain the mod calculations correctly, just print
out index + 1.
Comment 4 Dan Nicholson 2015-03-18 00:05:42 UTC 
Good call. On my single commit repo where mod == 1, I hadn't noticed that would break.
Comment 5 Matthew Barnes 2015-03-18 02:01:49 UTC 
Looks good, thanks for the patch!

I'll give Colin a chance to comment, but it looks pretty straightforward to me.
Comment 6 Colin Walters 2015-03-18 12:44:43 UTC 
(In reply to Matthew Barnes from comment #5)
> Looks good, thanks for the patch!
> 
> I'll give Colin a chance to comment, but it looks pretty straightforward to
> me.

I trust your review, please push, thanks!