X another example of wc1 invalidation bug related to ZBlk pinning to #blk

This one is less exotic compared to format changes rewrite.

bigfile/file_zodb.py

@@ -149,8 +149,13 @@ class ZBlkBase(Persistent):
     #       ZBigFile.storeblk() can change type of stored zblk - i.e. it rewrites
     #       ZBigFile.blktab[blk] with another ZBlk created anew.
     #
+    #       another example: a block may initially have no ZBlk attached (and
+    #       thus it reads as 0). However when data in that block is changes - a
+    #       new ZBlk is created, but information that block data has to be
+    #       invalidated is NOT correctly received by peers.
+    #
     # FIXME this assumes that ghostified ZBlk will never be removed from live
-    #       objects cache (cPicleCache). However, since ZBlk is not doing
+    #       objects cache (cPickleCache). However, since ZBlk is not doing
     #       anything special, and it actually becomes a ghost all the time (e.g.
     #       ZBlk0.loadblkdata() ghostifies itself not to waste memory), this
     #       assumption is NOT correct. Thus, if a ghost ZBlk will be removed from