From 878313b6d8faaac8319f85558318544be5aad7d9 Mon Sep 17 00:00:00 2001
From: short <>
Date: Wed, 13 Aug 2003 09:13:25 +0000
Subject: [PATCH] +Comments about AllocationSize/FileSize/ValidDataLength
 meaning.

---
 src/libcaptive/cc/sharedcachemap-priv.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/src/libcaptive/cc/sharedcachemap-priv.h b/src/libcaptive/cc/sharedcachemap-priv.h
index 0d69717..084948e 100644
--- a/src/libcaptive/cc/sharedcachemap-priv.h
+++ b/src/libcaptive/cc/sharedcachemap-priv.h
@@ -44,8 +44,20 @@ struct _CaptiveSharedCacheMapObject {
 	FILE_OBJECT *FileObject;
 	SECTION_OBJECT_POINTERS *SectionObjectPointers;
 	/* ValidDataLength<=FileSize<=AllocationSize */
+	/* 'AllocationSize' sets the mmap(2)ed area of buffers of this SharedCacheMap.
+	 * We must reallocate this area if 'AllocationSize' changes and in such case
+	 * there must exist no map-Bcb or pin-Bcbs for it.
+	 * We would cope with 'buffer' change with existing Bcbs but W32 client could not.
+	 */
 	guint64 AllocationSize;	/* ==CC_FILE_SIZES.AllocationSize.QuadPart */
+	/* We generally check against CAPTIVE_ROUND_UP64(FileSize,PAGE_SIZE)
+	 * as the offsets are usually PAGE_SIZE aligned due to pin-Bcb expectations.
+	 */
 	guint64 FileSize;	/* ==CC_FILE_SIZES.FileSize.QuadPart */
+	/* We use 'FileSize' instead of 'ValidDataLength' as I assume W32
+	 * automatically increases 'ValidDataLength' during Cache Manager write operations.
+	 * We do not increase it and therefore it is mostly useless for us.
+	 */
 	guint64 ValidDataLength;	/* ==CC_FILE_SIZES.ValidDataLength.QuadPart */
 	CACHE_MANAGER_CALLBACKS CallBacks;
 	VOID *LazyWriterContext;
-- 
1.8.3.1