[[!comment format=mdwn
 username="gleachkr@7c488e398809299a1100b93f8884de43dee83674"
 nickname="gleachkr"
 avatar="http://cdn.libravatar.org/avatar/c7ce6b5eae91547b25e9a05fc7c8cf22"
 subject="More data points"
 date="2017-09-16T01:16:59Z"
 content="""
the results of `git log` on one affected file are (the last commit being after I noticed the problem and tried to fix it)

    commit 0e93d1c9c18cf7aead978e0ae453e66991d6e500
    Author: Graham <alarm@localhost.localdomain>
    Date:   Tue Sep 12 19:20:33 2017 +0000

        attempt to fix references for Whitney

    commit 02bf95566eb2dd6947f417019e1d601abcfb55c1
    Author: Graham <gleachkr@gmail.com>
    Date:   Tue Aug 8 18:45:06 2017 -0500
    
        cleanup
    
    commit 655b0fd419945d0ea32d9d178c551af0a64e6afd
    Author: Graham <alarm@localhost.localdomain>
    Date:   Sat Nov 19 19:21:10 2016 +0000
    
        database cleanup
    
    commit 54fa420bcaf33847eee77a30fbd9556beea28f77
    Author: gleachkr <gleachkr@gmail.com>
    Date:   Fri Sep 9 17:48:48 2016 -0500
    
        git-annex in graham@Descartes:~/music

running `.dump` in sqlite3 yields the following two lines containing the key associated with one file suffering from the problem, with no lines containing both \"associated\" and the key (sorry, not a db expert):

    INSERT INTO content VALUES(171,'SHA256E-s8350646--d9bbbd67402a1b7560ebc47bc7bafaf74115a99c628e7458ba4754d8a355908a.m4a','I \"237 8350646 1473527901\"');
    INSERT INTO content VALUES(172,'SHA256E-s8350646--d9bbbd67402a1b7560ebc47bc7bafaf74115a99c628e7458ba4754d8a355908a.m4a','I \"1711652 8350646 1473527901\"');

another affected file shows up on lines:

    INSERT INTO associated VALUES(3,'SHA256E-s8789357--2bedeea689e7d7dda1e877989abd3e822f722c9bc45a14d1951d5dc104f4ad62.m4a','Car Seat Headrest/Teens of Denial/01 Fill in the Blank.m4a');
    INSERT INTO content VALUES(31,'SHA256E-s8789357--2bedeea689e7d7dda1e877989abd3e822f722c9bc45a14d1951d5dc104f4ad62.m4a','I \"135750 8789357 1473525850\"');
    INSERT INTO content VALUES(32,'SHA256E-s8789357--2bedeea689e7d7dda1e877989abd3e822f722c9bc45a14d1951d5dc104f4ad62.m4a','I \"1711014 8789357 1473525850\"');
    INSERT INTO content VALUES(296,'SHA256E-s8789357--2bedeea689e7d7dda1e877989abd3e822f722c9bc45a14d1951d5dc104f4ad62.m4a','I \"1050021 8789357 1498915821\"');

This second file has slightly different deviant behavior. It still registers as not present to `annex find` and `annex info`, is redownloaded by `annex get`, and shows up in `annex list`. But unlike the first, it does not register as not present when `annex fsck` is run. It just checks out, apparently.

The second file gives `git log` results as follows:

    commit 02bf95566eb2dd6947f417019e1d601abcfb55c1
    Author: Graham <gleachkr@gmail.com>
    Date:   Tue Aug 8 18:45:06 2017 -0500
    
        cleanup
    
    commit 655b0fd419945d0ea32d9d178c551af0a64e6afd
    Author: Graham <alarm@localhost.localdomain>
    Date:   Sat Nov 19 19:21:10 2016 +0000
    
        database cleanup
    
    commit 54fa420bcaf33847eee77a30fbd9556beea28f77
    Author: gleachkr <gleachkr@gmail.com>
    Date:   Fri Sep 9 17:48:48 2016 -0500
    
        git-annex in graham@Descartes:~/music
"""]]