bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 06/10] maint: remove r/hfs/DOC,HISTORY,TODO; add VERSION for new


From: Jim Meyering
Subject: [PATCH 06/10] maint: remove r/hfs/DOC,HISTORY,TODO; add VERSION for new library
Date: Fri, 3 Feb 2012 22:46:55 +0100

From: Jim Meyering <address@hidden>

---
 libparted/fs/Makefile.am   |   16 ++++--
 libparted/fs/r/hfs/DOC     |   92 -----------------------------------
 libparted/fs/r/hfs/HISTORY |  115 --------------------------------------------
 libparted/fs/r/hfs/TODO    |   27 ----------
 4 files changed, 11 insertions(+), 239 deletions(-)
 delete mode 100644 libparted/fs/r/hfs/DOC
 delete mode 100644 libparted/fs/r/hfs/HISTORY
 delete mode 100644 libparted/fs/r/hfs/TODO

diff --git a/libparted/fs/Makefile.am b/libparted/fs/Makefile.am
index b579381..9dd37fc 100644
--- a/libparted/fs/Makefile.am
+++ b/libparted/fs/Makefile.am
@@ -51,15 +51,21 @@ libfs_la_SOURCES =          \
   xfs/xfs_sb.h                 \
   xfs/xfs_types.h

-EXTRA_DIST = hfs/DOC hfs/HISTORY
-
 lib_LTLIBRARIES = libparted-fs-resize.la

 EXTRA_DIST =                   \
-  r/hfs/DOC                    \
-  r/hfs/HISTORY                        \
-  r/hfs/TODO
+  hfs/DOC                      \
+  hfs/HISTORY                  \
+  hfs/TODO
+
+# Set the shared library version, per Libtool's guidelines.
+# For details, see the "Updating library version information" section of
+# "info libtool".
+CURRENT = 0
+REVISION = 0
+AGE = 0

+libparted_fs_resize_la_LDFLAGS  = -version-info $(CURRENT):$(REVISION):$(AGE)
 libparted_fs_resize_la_SOURCES = \
   r/filesys.c                  \
   r/fat/bootsector.c           \
diff --git a/libparted/fs/r/hfs/DOC b/libparted/fs/r/hfs/DOC
deleted file mode 100644
index 9ee8b4d..0000000
--- a/libparted/fs/r/hfs/DOC
+++ /dev/null
@@ -1,92 +0,0 @@
-WARNING : Both HFS and HFS+ implementations of Linux 2.4 are buggy, at
-least when used before or after this implementation. Some workarounds
-are used in this implementation, but there can still be incompatibilities.
-Try Linux 2.6 if you want to play with HFS(+) resizing (though some bugs
-might also be there in 2.6, there is of course no warranty)
-
----
-
-    Technical doc about Apple HFS and HFS+ file systems is available at :
-    * For HFS, section "Data Organization on Volumes",
-                       "Chapter 2 - File Manager"
-           of the book "Inside Macintosh: Files"
-     http://developer.apple.com/documentation/mac/Files/Files-99.html
-    * For HFS+, "Technical Note TN1150", "HFS Plus Volume Format"
-     http://developer.apple.com/technotes/tn/tn1150.html
-
-    Some useful HFS precisions concerning alignement, bit ordering, and
-    order of fields for extent key comparaisons are only in the HFS+ TN
-
-    These Apple Creator Codes are reserved for us :
-    Shnk traP GP16 GnuP PH+x Xpnd Resz GP17 GP18 GP19 GP20
-
----
-
-* Cache design *
-
-Versions before HFS Patch 15 were very slow when data relocation was needed,
-because every extent to relocate involved scanning the whole file system,
-looking for a reference to its physical position on the volume (this was a
-dummy algorithm, I know :)
-
-HFS Patch 16 introduced a cache that allows to efficiently retrieve the place
-of the reference in the file system given the physical position of an extent.
-The cache is designed for : - efficiency
-                           - scaling
-                           - simplicity
-                           - avoiding memory allocation while resizing
-
-This cache involves quite big worst case memory consumption, but without it
-the time needed to complete the operation in the worst case would be huge
-anyway (maybe several years...) so this isn't really an issue. The cache size
-is nearly proportional to the number of files you have, or if you have very few
-files, to the size of your volume, so worst cases situations occure when you
-fill a drive with millions of < 4 ko files :p For this very special usage you
-will just need a very special amount of RAM (on typical systems about
-(FS size) / 256 )... On a more "normal" volume it's about
-(# of files) * 20 bytes. With very few files it's about (FS Size) / 1024 / 256.
-
-At the beginning of the resize process, the cache is filed by scanning the FS.
-The position of each extent is cut into 2 parts : high order is used as
-an index into a table of pointer to a linked list which contains :
-- the next ptr                         (sizeof struct *)
-- the extent start                     (4 bytes)
-- the extent size                      (4 bytes)
-- number of BTree block or 0 if in prim (4 bytes)
-- offset of the extent start reference
-  from the block beginning              (2 bytes)
-- sectors by BTree block, or
-  1 for VH/MDB                         (1 byte)
-- FS special file / primary structure
-  where the extent reference is stored  (1 byte)
-  (3 bits for the extent index, 5 for
-   the actual ref)
-
-  0 : dont exists                              --- reserved
-  1 : mdb / vh : catalog                       ---
-  2 : mdb / vh : extent                                ---
-  3 :       vh : attributes                    X+-
-  4 :       vh : allocation                    X+-
-  5 :       vh : startup                       X+-
-  6 :            catalog                       ---
-  7 :            attributes                    X+-
-  8 :            extent (nothing to update)    ---
-  9 :            extent (update catalog)       ---
- 10 :            extent (update extent !?!)    --- should not exist
- 11 :            extent (update attributes)    X+-
- 12 :            extent (update allocation)    X+-
- 13 :            extent (update startup)       X+- reserved
- 14 :       vh : journal info block            X+J
- 15 :       jib: journal                       X+J
- 16 - 31 :                                     ---
-
-mdb : Master Directory Block
-vh  : Volume Header
-X+  : HFSX or HFS+ only
-J   : Journaled only
-
-Large amount of memory is allocated at once (first enough memory to fit
-every files if there isn't any fragmentation +6.25%, then this value / 4,
-if this wasn't enough). On a typical FS, the first allocation should be enough.
-
----
diff --git a/libparted/fs/r/hfs/HISTORY b/libparted/fs/r/hfs/HISTORY
deleted file mode 100644
index 5e138a6..0000000
--- a/libparted/fs/r/hfs/HISTORY
+++ /dev/null
@@ -1,115 +0,0 @@
-## modifications                                               dd-mm-yyyy
----------------------- PATCH FOR PARTED 1.6.5 ----------------------------
- 1 initial revision                                            07-04-2003
- 2 one pass resizing, removal of debug info                    08-04-2003
- 3 safe abort if resize failed, code cleanups, timer,          10-04-2003
-   source file split, won't resize if not unmounted,
-   only relocate data if needed, minimize disk operations
- 4 memory leaks removal, code cleanups, resize hfs+ code,      17-04-2003
-   more checks, minor hfs resize bugfix, probe code
-   returns real geometry
- 5 hfs+ resize bugfixes :                                      19-04-2003
-   * fragmented fs could be corrupted
-   * VH wasn't written on error during alloc map writing
-   * attributes file could be corrupted
- 6 Use PedSector to be able to use 2To+ HD                     23-04-2003
-   Minor probe bugfix, Cleanups, HFS+ Timer tuning,
- 7 80 columns indentation                                      23-04-2003
- 8 Bugfix free blocks calculation in wrapper
-   (makes Mac OS boot !)                                       28-04-2003
----------------------- PATCH FOR PARTED 1.6.6 ----------------------------
- 9 Don't destroy the file being worked on in case of
-   interruption of Parted                                      28-10-2003
----------------------- PATCH FOR PARTED 1.6.10 ---------------------------
-10 Regression tests, URL correction, In effect_move_extent :
-   corrected memory leak & corrected a bug in precondition checks
-   Added error messages, Check ped_alloc results
-   Use macro for test / set / clear in the allocation bitmap
-   Light probe correction, Check return value of get_empty_end
-   Moved dynamic memory allocation out of effect_move_extent
-   Check HFS+ version, Set implementation creator code
-   Check journal absence, Corrected a bug in HFS+ block number
-   calculation                                                 24-04-2004
---------------------- PATCH FOR PARTED 1.6.11 ----------------------------
-11-Some pointer dereference moved after non nul assertion
-  -Error messages for HFS(+) file IO
-  -Memory leak correction in hfs(plus)_read_bad_blocks
-  -Mark out of volume blocks as used
-    (improve compatibility with broken HFS+ Linux
-    implementation)
-   WARNING : this fix is not 100% tn1150 compatible :
-   "The allocation file may be larger than the minimum
-   number of bits required for the given volume size.
-   Any unused bits in the bitmap must be set to _zero_."
-   Anyway neither is the Linux implementation, nor was my
-   previous implementations
-   Maybe I should ask Apple to change the specifications
-  -HISTORY, DOC and TODO files                                 29-04-2004
-12 Corrected a bug in hfsplus_volume_resize : size of alloc
-   bitmap could be miscalculated                               29-04-2004
---------------------- PATCH FOR PARTED 1.6.12 ----------------------------
-13-Finally partial rewrite of *_search_move_*
-   Easier to maintain and prepare for extent search and
-   relocation algorithm changes for better ones.
-  -"An extent has not been relocated!" message now only when
-   relocation requested
-  -Slightly better and simpler relocation algorithm
-  -Update of Makefile.in and Makefile.am in fs_hfs
-  -Sign correction for some 8bits HFS integers
-  -Added the option --enable-hfs-extract-fs in 'configure'
-  -Added every ped_geometry_sync where needed
-  -Bugfix : "A root node does not need to exist
-               (if the tree is empty)."
-           - now handled correctly in btree_search
-  -Bugfix : failure wasn't detected in some cases
-           during 2 pass relocation (*_search_move_*)
-  -Bugfix : The extent key comparaison was done in a wrong order
-           and a pad field was used during the comparaison
-  -Bugfix : in hfs_file_find_sector and hfsplus_file_find_sector
-            the absolute position of a file sector could be
-           miscalculated in case of fragmentation, resulting
-           in potential data corruption, or various errors
-  -Bugfix : The end of the HFS bitmap compatibility block was
-           miscalculated ( (1<<16)/8 instead of (1<<16) )
-           in hfs_resize
-                                                               07-09-2004
---------------------- PATCH FOR PARTED 1.6.14 ----------------------------
-14 Port of Patch 13 for Parted 1.6.14 (update timestamps)
-                                                               08-09-2004
---------------------- PATCH FOR PARTED 1.6.15 ----------------------------
-15-hfsplus_open : added a warning message if the "attributes"
-   special file exists
-  -hfsplus_open : added a test to check if the "allocation"
-   special file has been correctly opened
-  -optimisation of hfs+ block access : don't recalculate
-   the address of each sector, and avoid checking the cache if
-   obviously not useful
-   ( hfsplus_file_read && hfsplus_file_write
-     && hfsplus_file_find_extent && hfs_file_find_sector)
-  -cut the "hfs.c" file in several parts
-  -Bugfix: in hfsplus_do_move_primary, hfs_effect_move_extent
-   was called instead of hfsplus_effect_move_extent !!!
-   This could not produce data corruption, because of a welcome
-   ASSERT in *_effect_move_extent that would detect the bug :)
-  -Bugfix: in hfs_effect_move_extent, do
-       PED_ASSERT(*ptr_to_fblock <= *ptr_fblock, return -1);
-   instead of
-       PED_ASSERT(*ptr_to_fblock < *ptr_fblock, return -1);
-   and added that assertion to hfsplus_effect_move_extent
-  -Bugfix: bugs introduced in rewrite of hfsplus_file_read
-   && hfsplus_file_write : last sector was incorrectly detected
-   as out of file.
-  -Cache the extent references (speed improvement ?)
-                                                               23-09-2004
-16-Bugfix: in hfsplus_do_move (reloc_plus.c), case CR_BTREE_EXT_ATTR
-   incorrectly updated the cached part of priv_data->catalog_file
-   instead of priv_data->attributes_file
-  -Bugfix: in hfs_read_bad_blocks && hfsplus_read_bad_blocks,
-   now generate an error if file_ID or type mismatch after the
-   first pass
-   Also check return value of ped_malloc
-  -Bugfix: in hfsplus_btree_search, check return value of ped_malloc
-                                                               29-09-2004
----------------- INTEGRATION IN PARTED 1.6.22 (cvs) ----------------------
-Futur changes will be described in ../../ChangeLog
-                                                               02-02-2005
diff --git a/libparted/fs/r/hfs/TODO b/libparted/fs/r/hfs/TODO
deleted file mode 100644
index 6e408e3..0000000
--- a/libparted/fs/r/hfs/TODO
+++ /dev/null
@@ -1,27 +0,0 @@
---- TODO ---
-
-   * Continue to write regressions tests and try on 2.6 kernel  -- (high)
-   * Fix timer progression calculation, according to the new
-     caching code                                              -- (high)
-   * write doc, website, ...                                   -- (high)
-   * Check block allocation in linux 2.4 and remove
-     compatibility code if possible                            -- (high)
-
-   * In hfs(plus)_btree_search , use a static variable to detect
-     illegal recursion and abort in that case. (find the right
-     number of recursion before reporting bug) -- easy         -- (medium)
-   * Finish the HFS Extractor                                  -- (medium)
-     (add mdb & vh extraction, and maybe journal)
-
-   * Write code to allow enlarging and moving HFS[+x]          -- (low)
-   * Use a bitmap to internaly store the bad blocks            -- (low)
-   * Less bitmap saves ?                                       -- (low)
-   * Continue to change the relocation algorithm
-     for a better one :)                                       -- (low)
-
---- NOT todo ---
-
-   * debug HFS(+) Linux implementation (block allocation for HFS+,
-     hard and sym links for HFS+, filename length for HFS, ...)        -- 
(dont)
-       /// Linux 2.6 contains HFS(+) implementations with less bugs
-       /// Linux 2.4 should not be used anymore to access HFS(+)
-- 
1.7.9.112.gb85f2




reply via email to

[Prev in Thread] Current Thread [Next in Thread]