Lines Matching full:remap
246 I started immediately with constructing a simple <Literal remap="tt">hex editor</Literal> - It would
248 filesystem with a simple <Literal remap="tt">offset</Literal> method, and just show a
249 <Literal remap="tt"> hex dump</Literal> of the contents at this point. Programming this was trivially
263 main include file - <Literal remap="tt">/usr/include/linux/ext2_fs.h</Literal>. Among its contents
269 I wanted a <Literal remap="tt">quick</Literal> way to get going. I didn't have the patience to learn
276 So after the <Literal remap="tt">hex editor</Literal>, EXT2ED progressed into a tool which has some
277 elements of a compiler. I programmed EXT2ED to <Literal remap="tt">dynamically read the kernel
279 was to <Literal remap="tt">imply a structure-definition on the current offset at the
286 are mostly <Literal remap="tt">flat</Literal> - Didn't contain a lot of recursive structure; Only a
295 To handle the task, I constructed the <Literal remap="tt">struct_descriptor</Literal> structure.
296 Each <Literal remap="tt">struct_descriptor instance</Literal> contained information which is needed
330 <Literal remap="tt">current structure type</Literal> - A pointer to the relevant
331 <Literal remap="tt">struct_descriptor</Literal>.
402 basic concepts - The <Literal remap="tt">superblock</Literal>, for example. It seems that the
412 signature - A <Literal remap="tt">magic number</Literal> - EXT2_SUPER_MAGIC (0xEF53 - EF probably
414 fixed offset 1024 in the filesystem - The <Literal remap="tt">s_magic</Literal> variable in the
419 It seems that starting with the <Literal remap="tt">superblock</Literal> was a good bet - Just from
473 design, and needs a <Literal remap="tt">fine tuned handling</Literal>. It is at this point that the
474 structure definitions <Literal remap="tt">came to life</Literal> - They became <Literal remap="tt">object
475 definitions</Literal>, making EXT2ED <Literal remap="tt">object oriented</Literal>.
480 now had a list of <Literal remap="tt">private commands</Literal>, which ended up in
481 <Literal remap="tt">calling special fine-tuned C functions</Literal>. This approach was
482 found to be very powerful and is <Literal remap="tt">the heart of EXT2ED even now</Literal>.
487 <Literal remap="tt">struct_commands</Literal>. The role of this structure is to group together a
509 <Literal remap="tt">struct_descriptor</Literal> structure (explained earlier) was added a private
510 <Literal remap="tt">struct_commands</Literal> structure.
514 Follows the current definitions of <Literal remap="tt">struct_descriptor</Literal> and of
515 <Literal remap="tt">struct_command</Literal>:
578 <Literal remap="tt">general command</Literal>, selectable from a list of general commands which was
579 always available, or a <Literal remap="tt">type specific command</Literal>, selectable from a list of
580 commands which <Literal remap="tt">changed in time</Literal> according to the current type that the
581 user was editing. The special <Literal remap="tt">type specific command</Literal> "knew" how to
588 type <Literal remap="tt">struct_commands</Literal>, which contained the <Literal remap="tt">general commands</Literal>.
589 The <Literal remap="tt">type specific commands</Literal> were accessible through the <Literal remap="tt">struct
606 Analyze the user command - Separate it into <Literal remap="tt">command</Literal> and
607 <Literal remap="tt">arguments</Literal>.
635 Note the <Literal remap="tt">order</Literal> of the above steps. In particular, note that a command
637 general command is searched. The "<Literal remap="tt">side-effect</Literal>" (main effect, actually)
638 is that when we have two commands with the <Literal remap="tt">same name</Literal> - One that is a
640 algorithm will call the <Literal remap="tt">type specific command</Literal>. This allows
641 <Literal remap="tt">overriding</Literal> of a command to provide <Literal remap="tt">fine-tuned</Literal> operation.
642 For example, the <Literal remap="tt">show</Literal> command is overridden nearly everywhere,
648 The above is done in the <Literal remap="tt">dispatch</Literal> function, in <Literal remap="tt">main.c</Literal>. Since
721 <Literal remap="tt">Main include file - ext2ed.h</Literal>
732 <Literal remap="tt">Main block - main.c</Literal>
734 <Literal remap="tt">main.c</Literal> handles the upper level of the program flow control.
735 It contains the <Literal remap="tt">parser</Literal> and the <Literal remap="tt">dispatcher</Literal>. Its task is
744 <Literal remap="tt">Initialization - init.c</Literal>
757 <Literal remap="tt">Disk activity - disk.c</Literal>
759 <Literal remap="tt">disk.c</Literal> is handles the lower level interaction with the
770 <Literal remap="tt">Display output activity - win.c</Literal>
772 In a similar way to <Literal remap="tt">disk.c</Literal>, the user-interface functions and
773 most of the interaction with the <Literal remap="tt">ncurses library</Literal> are done
782 <Literal remap="tt">Commands available through dispatching - *_com.c </Literal>
785 <Literal remap="tt">_com.c</Literal> contains a group of related commands which can be
786 called through <Literal remap="tt">the dispatching function</Literal>.
897 The <Literal remap="tt">ncurses</Literal> library, developed by <Literal remap="tt">Zeyd Ben-Halim</Literal>.
903 The <Literal remap="tt">GNU readline</Literal> library.
913 line, which consists of a <Literal remap="tt">command</Literal> and of <Literal remap="tt">arguments</Literal>. This fits
914 nicely with the program flow control described earlier - The <Literal remap="tt">command</Literal>
915 is used by <Literal remap="tt">dispatch</Literal> to select the right function, and the
916 <Literal remap="tt">arguments</Literal> are interpreted by the function itself.
923 The <Literal remap="tt">ncurses</Literal> library enables me to divide the screen into "windows".
932 <Literal remap="tt">ncurses</Literal> library, while I can still treat it in a virtual way.
936 There are two basic concepts in the <Literal remap="tt">ncurses</Literal> library:
992 The <Literal remap="tt">title window</Literal> is static - It just displays the current version
997 The user interaction is done in the <Literal remap="tt">command window</Literal>. The user enters a
998 <Literal remap="tt">command line</Literal>, feedback is usually displayed there, and then relevant
1003 The <Literal remap="tt">main display</Literal> is using a <Literal remap="tt">pad</Literal> instead of a window because
1006 display and can <Literal remap="tt">scroll vertically</Literal> using the <Literal remap="tt">pgdn</Literal> and <Literal remap="tt">pgup</Literal>
1007 commands. Although the <Literal remap="tt">pad</Literal> mechanism enables me to use horizontal
1012 When I need to show something to the user, I use the ncurses <Literal remap="tt">wprintw</Literal>
1014 the refresh commands is piped through <Literal remap="tt">win.c</Literal>. For example, to update
1015 the command window, <Literal remap="tt">refresh_command_win ()</Literal> is used.
1024 Avner suggested me to integrate the GNU <Literal remap="tt">readline</Literal> library in my project.
1025 The <Literal remap="tt">readline</Literal> library is designed specifically for programs which use
1026 command line interface. It provides a nice package of <Literal remap="tt">command line editing
1028 which are normally available in the <Literal remap="tt">bash</Literal> shell (Refer to the readline
1029 documentation for details). In addition, I utilized the <Literal remap="tt">history</Literal>
1031 <Literal remap="tt">command history</Literal>, and can be called later by whatever means that the
1073 The general commands are provided by the <Literal remap="tt">general_com.c</Literal> source file,
1075 loads - They are dynamically added by <Literal remap="tt">init.c</Literal> when EXT2ED detects an
1089 primitive <Literal remap="tt">setoffset</Literal> and <Literal remap="tt">settype</Literal> commands.
1106 The various commands are reached by the user through the <Literal remap="tt">dispatch</Literal>
1108 a first look, is that <Literal remap="tt">you'll find the dispatch call in many of my
1115 is object oriented ant that the <Literal remap="tt">overriding</Literal> principle takes place and
1122 through <Literal remap="tt">dispatch</Literal>. This is typically done when I want to bypass the
1123 <Literal remap="tt">overriding</Literal> effect.
1184 I chose a unified <Literal remap="tt">naming convention</Literal> for the various object
1187 The prototype of the handling function of the command <Literal remap="tt">next</Literal> of
1188 the type <Literal remap="tt">file</Literal> is:
1196 For other types and commands, the words <Literal remap="tt">file</Literal> and <Literal remap="tt">next</Literal>
1205 general command <Literal remap="tt">super</Literal> results in calling:
1212 Those functions are available in <Literal remap="tt">ext2_com.c</Literal>.
1220 functions are available in <Literal remap="tt">general_com.c</Literal>.
1255 Use some <Literal remap="tt">dispatch / direct </Literal> calls in order to pass control to
1262 Sometimes <Literal remap="tt">dispatch</Literal> to the object's <Literal remap="tt">show</Literal> command to
1283 routines available in the source file <Literal remap="tt">init.c</Literal>.
1290 Follows the function <Literal remap="tt">main</Literal>, appearing of-course in <Literal remap="tt">main.c</Literal>:
1311 The two initialization functions, which are called by <Literal remap="tt">main</Literal>, are:
1335 <Literal remap="tt">init</Literal> is called from <Literal remap="tt">main</Literal> upon startup. It initializes the
1342 Processing of the <Literal remap="tt">user configuration file</Literal>, by using the
1343 <Literal remap="tt">process_configuration_file</Literal> function. Failing to complete the
1344 configuration file processing is considered a <Literal remap="tt">fatal error</Literal>,
1353 Registration of the <Literal remap="tt">general commands</Literal> through the use of
1354 the <Literal remap="tt">add_general_commands</Literal> function.
1373 ncurses library and EXT2ED, through the use of the <Literal remap="tt">init_windows</Literal>
1374 function, available in <Literal remap="tt">win.c</Literal>.
1381 EXT2ED, through <Literal remap="tt">init_readline</Literal>.
1387 Initialization of the <Literal remap="tt">signals</Literal> subsystem, through
1388 <Literal remap="tt">init_signals</Literal>.
1401 When <Literal remap="tt">init</Literal> is finished, it dispatches the <Literal remap="tt">help</Literal> command in order
1413 The <Literal remap="tt">prepare_to_close</Literal> function reverses some of the actions done
1428 the use of <Literal remap="tt">free_user_commands</Literal>, with a pointer to the
1443 specific commands, by using <Literal remap="tt">free_struct_descriptors</Literal>.
1450 library, through the use of the <Literal remap="tt">close_windows</Literal> function,
1451 available in <Literal remap="tt">win.c</Literal>.
1467 Addition of a user command is done through the <Literal remap="tt">add_user_command</Literal>
1476 <Literal remap="tt">struct_commands</Literal>, a desired name for the command which will be used by
1478 <Literal remap="tt">help</Literal> subsystem, and a pointer to a C function which will be called if
1479 <Literal remap="tt">dispatch</Literal> decides that this command was requested.
1483 The <Literal remap="tt">add_user_command</Literal> is a <Literal remap="tt">low level function</Literal> used in the three
1484 levels to add user commands. For example, addition of the <Literal remap="tt">ext2
1507 <Literal remap="tt">struct</Literal> keyword. The primitive parser I have implemented detects the
1533 <Literal remap="tt">add_new_descriptor</Literal> is a low level function which adds a new descriptor
1535 <Literal remap="tt">fill_type_commands</Literal>, which will add specific commands to the object,
1540 <Literal remap="tt">add_new_variable</Literal> will add a new variable of the requested length to the
1550 When the general command <Literal remap="tt">setdevice</Literal> is used to open a device, some
1571 This questions are answered by the <Literal remap="tt">set_file_system_info</Literal>, possibly
1572 using some <Literal remap="tt">help from the user</Literal>, through the configuration file.
1573 The answers are placed in the <Literal remap="tt">file_system_info</Literal> structure, which is of
1574 type <Literal remap="tt">struct_file_system_info</Literal>:
1595 <Literal remap="tt">override</Literal> the auto detection procedure and force an ext2 filesystem, by
1607 If we decide to treat the filesystem as an ext2 filesystem, <Literal remap="tt">registration of
1609 <Literal remap="tt">set_struct_descriptors</Literal> outlined earlier, with the name of the file
1617 <Literal remap="tt">limited form</Literal>, but more sophisticated than a simple hex editor.
1628 As described earlier, <Literal remap="tt">main.c</Literal> is used as a front-head to the entire
1629 program. <Literal remap="tt">main.c</Literal> contains the following elements:
1636 The <Literal remap="tt">main</Literal> routine was displayed above. Its task is to pass control to
1652 The <Literal remap="tt">parser</Literal> function, which reads the command line from the
1660 The <Literal remap="tt">parse_word</Literal> function, which receives a string and parses
1668 The <Literal remap="tt">complete_command</Literal> function, which is used by the readline
1701 double checked myself in a few instances, and issued an <Literal remap="tt">internal
1703 The internal error is reported by the function <Literal remap="tt">internal_error</Literal>,
1704 available in <Literal remap="tt">main.c</Literal>.
1709 <Literal remap="tt">DEBUG</Literal> is selected.
1720 Screen handling and interfacing to the <Literal remap="tt">ncurses</Literal> library is done in
1721 <Literal remap="tt">win.c</Literal>.
1728 Opening of the windows is done in <Literal remap="tt">init_windows</Literal>. In
1729 <Literal remap="tt">close_windows</Literal>, we just close our windows. The various window lengths
1730 with an exception to the <Literal remap="tt">show pad</Literal> are defined in the main header file.
1731 The rest of the display will be used by the <Literal remap="tt">show pad</Literal>.
1741 appropriate refresh function from this file: <Literal remap="tt">refresh_title_win</Literal>,
1742 <Literal remap="tt">refresh_show_win</Literal>, <Literal remap="tt">refresh_show_pad</Literal> and
1743 <Literal remap="tt">refresh_command_win</Literal>.
1747 With the exception of the <Literal remap="tt">show pad</Literal>, each function simply calls the
1748 <Literal remap="tt">ncurses refresh command</Literal>. In order to provide to <Literal remap="tt">scrolling</Literal> in
1749 the <Literal remap
1750 by the various functions which display output in it. <Literal remap="tt">refresh_show_pad</Literal>
1751 passes this information to <Literal remap="tt">ncurses</Literal> so that the correct part of the pad
1756 The above information is saved in a global variable of type <Literal remap="tt">struct
1779 The <Literal remap="tt">redraw_all</Literal> function will just reopen the windows. This action is
1792 <Literal remap="tt">disk.c</Literal>. This is done that way to provide additional levels of safety
1802 Read requests are ultimately handled by <Literal remap="tt">low_read</Literal> and write requests
1803 are handled by <Literal remap="tt">low_write</Literal>. They just receive the length of the data
1805 request to the <Literal remap="tt">fread</Literal> or <Literal remap="tt">fwrite</Literal> standard library functions.
1815 a <Literal remap="tt">reasonably simple</Literal> way to handle mounted filesystems exists, it is
1816 probably <Literal remap="tt">too complicated</Literal> :-)
1832 intended for <Literal remap="tt">editing filesystems</Literal>. It is obvious that a small mistake
1849 The filesystem is <Literal remap="tt">never</Literal> opened with write-access enables.
1856 The user can <Literal remap="tt">disable</Literal> write access entirely by using a
1857 <Literal remap="tt">configuration file option</Literal>.
1864 changes, they are done in memory. An explicit <Literal remap="tt">writedata</Literal>
1884 Limiting <Literal remap="tt">actual</Literal> filesystem access to two functions only -
1885 <Literal remap="tt">low_read</Literal> for reading, and <Literal remap="tt">low_write</Literal> for writing. Those
1892 is double checked here only as a <Literal remap="tt">self-sanity</Literal> check - If
1893 <Literal remap="tt">DEBUG</Literal> is selected, since write enable should have been refused
1895 <Literal remap="tt">here</Literal> that the user has write access disabled through the
1905 The following safety measure can provide protection against <Literal remap="tt">both</Literal> user
1912 I added a <Literal remap="tt">logging option</Literal>, which logs every actual write
1913 access to the disk in the lowest level - In <Literal remap="tt">low_write</Literal> itself.
1926 (This assumes, of-course, that <Literal remap="tt">low-write</Literal> and the <Literal remap="tt">logging
1930 The <Literal remap="tt">logging</Literal> option is implemented in the <Literal remap="tt">log_changes</Literal>
1945 Usually <Literal remap="tt">(not always)</Literal>, the current object data is available in the
1946 global variable <Literal remap="tt">type_data</Literal>, which is of the type:
1971 the functions <Literal remap="tt">load_type_data</Literal> and <Literal remap="tt">write_type_data</Literal>, available in
1972 <Literal remap="tt">disk.c</Literal>.
1983 The <Literal remap="tt">general commands</Literal> are handled in the file <Literal remap="tt">general_com.c</Literal>.
1990 The help command is handled by the function <Literal remap="tt">help</Literal>. The algorithm is as
2001 control to the <Literal remap="tt">detailed_help</Literal> function, in order to provide
2034 The <Literal remap="tt">setdevice</Literal> commands result in calling the <Literal remap="tt">set_device</Literal>
2058 <Literal remap="tt">device_name</Literal> and <Literal remap="tt">device_handle</Literal>.
2077 <Literal remap="tt">free_user_commands</Literal>.
2083 Unregister the current objects, using <Literal remap="tt">free_struct_descriptors</Literal>
2089 Call <Literal remap="tt">set_file_system_info</Literal> to auto-detect an ext2 filesystem
2096 Add the <Literal remap="tt">alternate descriptors</Literal>, supplied by the user.
2103 <Literal remap="tt">setoffset 0</Literal>.
2109 Show the new available commands by dispatching the <Literal remap="tt">help</Literal>
2124 Basic maneuvering is done using the <Literal remap="tt">setoffset</Literal> and the <Literal remap="tt">settype</Literal>
2129 <Literal remap="tt">set_offset</Literal> accepts some alternative forms of specifying the new
2130 offset. They all ultimately lead to changing the <Literal remap="tt">device_offset</Literal>
2131 global variable and seeking to the new position. <Literal remap="tt">set_offset</Literal> also
2132 calls <Literal remap="tt">load_type_data</Literal> to read a block ahead of the new position into
2133 the <Literal remap="tt">type_data</Literal> global variable.
2137 <Literal remap="tt">set_type</Literal> will point the global variable <Literal remap="tt">current_type</Literal> to the
2139 requested type is <Literal remap="tt">hex</Literal> or <Literal remap="tt">none</Literal>, <Literal remap="tt">current_type</Literal> will be
2140 initialized to <Literal remap="tt">NULL</Literal>. <Literal remap="tt">set_type</Literal> will also dispatch <Literal remap="tt">show</Literal>,
2157 The general command version of <Literal remap="tt">show</Literal> is handled by the <Literal remap="tt">show</Literal>
2163 The general show command will format the data in <Literal remap="tt">type_data</Literal> according
2164 to the structure definition of the current type and show it on the <Literal remap="tt">show
2170 A call to <Literal remap="tt">show_info</Literal> is also made - <Literal remap="tt">show_info</Literal> will provide
2171 <Literal remap="tt">general statistics</Literal> on the <Literal remap="tt">show_window</Literal>, such as the current
2176 The <Literal remap="tt">pgup</Literal> and <Literal remap="tt">pgdn</Literal> general commands just update the
2177 <Literal remap="tt">show_pad_info</Literal> global variable - We just increment
2178 <Literal remap="tt">show_pad_info.line</Literal> with the number of lines in the screen -
2179 <Literal remap="tt">show_pad_info.display_lines</Literal>, which was initialized in
2180 <Literal remap="tt">init_windows</Literal>.
2190 explicit <Literal remap="tt">writedata</Literal> command to the disk. The <Literal remap="tt">write_data</Literal>
2191 function simple calls the <Literal remap="tt">write_type_data</Literal> function, outlined earlier.
2195 The <Literal remap="tt">set</Literal> command is used for changing the data.
2199 If there is no current type, control is passed to the <Literal remap="tt">hex_set</Literal> function,
2201 <Literal remap="tt">type_data.offset_in_block</Literal> variable to write the new text or hex string
2211 The <Literal remap="tt">enablewrite</Literal> commands just sets the global variable
2212 <Literal remap="tt">write_access</Literal> to <Literal remap="tt">1</Literal> and re-opens the filesystem in read-write
2217 If the current type is NULL, a hex-mode is assumed - The <Literal remap="tt">next</Literal> and
2218 <Literal remap="tt">prev</Literal> commands will just update <Literal remap="tt">type_data.offset_in_block</Literal>.
2222 If the current type is not NULL, the The <Literal remap="tt">next</Literal> and <Literal remap="tt">prev</Literal> command
2225 to the next / prev element by dispatching to <Literal remap="tt">setoffset</Literal> using the
2226 <Literal remap="tt">setoffset type + / - X</Literal> syntax.
2237 The ext2 general commands are contained in the <Literal remap="tt">ext2_general_commands</Literal>
2238 global variable (which is of type <Literal remap="tt">struct struct_commands</Literal>).
2242 The handling functions are implemented in the source file <Literal remap="tt">ext2_com.c</Literal>.
2268 It involves only setting the <Literal remap="tt">copy_num</Literal> variable to indicate the main
2269 copy, dispatching a <Literal remap="tt">setoffset</Literal> command to reach the superblock, and
2270 dispatching a <Literal remap="tt">settype</Literal> to enable the superblock specific commands.
2271 This last command will also call the <Literal remap="tt">show</Literal> command of the
2272 <Literal remap="tt">ext2_super_block</Literal> type, through dispatching at the general command
2273 <Literal remap="tt">settype</Literal>.
2284 <Literal remap="tt">ext2_group_desc</Literal>:
2306 The implementation is as trivial as the <Literal remap="tt">super</Literal> implementation. Note
2307 the use of the <Literal remap="tt">entry</Literal> command, which is a command of the
2308 <Literal remap="tt">ext2_group_desc</Literal> object, to pass to the correct group descriptor.
2317 The <Literal remap="tt">cd</Literal> command performs the usual cd function. The path to the global
2318 cd command is a path from <Literal remap="tt">/</Literal>.
2322 <Literal remap="tt">This is one of the best examples of the power of the object oriented
2362 <Literal remap="tt">super</Literal> is used to get to the superblock. <Literal remap="tt">group</Literal> to get to the
2363 first group descriptor. <Literal remap="tt">inode</Literal> brings us to the first inode - The bad
2364 blocks inode. A <Literal remap="tt">next</Literal> is command to pass to the root directory inode,
2365 a <Literal remap="tt">dir</Literal> command "enters" the directory, and then we let the <Literal remap="tt">object
2366 specific cd command</Literal> to take us from there (The object is <Literal remap="tt">dir</Literal>, so
2367 that <Literal remap="tt">dispatch</Literal> will call the <Literal remap="tt">cd</Literal> command of the <Literal remap="tt">dir</Literal> type).
2373 I feel that the above is <Literal remap="tt">intuitive</Literal> - I was expressing myself "in the
2398 The superblock object is <Literal remap="tt">ext2_super_block</Literal>. The definition is just
2403 Those lines of source are copyrighted by <Literal remap="tt">Remy Card</Literal> - The author of the
2404 ext2 filesystem, and by <Literal remap="tt">Linus Torvalds</Literal> - The first author of the Linux
2452 Note that I <Literal remap="tt">expanded</Literal> the array due to my primitive parser
2453 implementation. The various fields are described in the <Literal remap="tt">technical
2463 This section explains the commands available in the <Literal remap="tt">ext2_super_block</Literal>
2464 type. They all appear in <Literal remap="tt">super_com.c</Literal>
2471 The <Literal remap="tt">show</Literal> command is overridden here in order to provide more
2472 information than just the list of variables. A <Literal remap="tt">show</Literal> command will end
2473 up in calling <Literal remap="tt">type_super_block___show</Literal>.
2477 The first thing that we do is calling the <Literal remap="tt">general show command</Literal> in
2488 We also display the <Literal remap="tt">backup copy number</Literal> of the superblock in the status
2489 window. This copy number is saved in the <Literal remap="tt">super_info</Literal> global variable -
2490 <Literal remap="tt">super_info.copy_num</Literal>. Currently, this is the only variable there ...
2501 The <Literal remap="tt">current copy number</Literal> is available in <Literal remap="tt">super_info.copy_num</Literal>. It
2502 was initialized in the ext2 command <Literal remap="tt">super</Literal>, and is used by the various
2507 The <Literal remap="tt">gocopy</Literal> routine will pass to another copy of the superblock. The
2509 <Literal remap="tt">file_system_info</Literal> structure. Then the routine will <Literal remap="tt">dispatch</Literal> to
2510 the <Literal remap="tt">setoffset</Literal> and the <Literal remap="tt">show</Literal> routines.
2514 The <Literal remap="tt">setactivecopy</Literal> routine will just save the current superblock data
2515 in a temporary variable of type <Literal remap="tt">ext2_super_block</Literal>, and will dispatch
2516 <Literal remap="tt">gocopy 0</Literal> to pass to the main superblock. Then it will place the saved
2542 variable <Literal remap="tt">group_info</Literal>, which is of type <Literal remap="tt">struct_group_info</Literal>:
2557 <Literal remap="tt">group_num</Literal> is the index of the current descriptor in the table.
2561 <Literal remap="tt">copy_num</Literal> is the number of the current backup copy.
2587 <Literal remap="tt">blockbitmap, inodebitmap and inode</Literal> objects.
2596 Movement in the group descriptors table is done using the <Literal remap="tt">next, prev and
2597 entry</Literal> commands. Note that the first two commands <Literal remap="tt">override</Literal> the
2598 general commands of the same name. The <Literal remap="tt">next and prev</Literal> command are just
2599 calling the <Literal remap="tt">entry</Literal> function to do the job. I will show <Literal remap="tt">next</Literal>,
2623 The <Literal remap="tt">entry</Literal> function is also simple - It just calculates the offset
2624 using the information in <Literal remap="tt">group_info</Literal> and in <Literal remap="tt">file_system_info</Literal>,
2625 and uses the usual <Literal remap="tt">setoffset / show</Literal> pair.
2634 As usual, the <Literal remap="tt">show</Literal> command is overridden. The implementation is
2637 the <Literal remap="tt">group_info</Literal> structure.
2656 From a group descriptor, one typically wants to reach an <Literal remap="tt">inode</Literal>, or
2657 one of the <Literal remap="tt">allocation bitmaps</Literal>. This is done using the <Literal remap="tt">inode,
2660 structures of the next type, and issue the <Literal remap="tt">setoffset / settype</Literal> pair.
2664 For example, here is the implementation of the <Literal remap="tt">blockbitmap</Literal> command:
2754 supports <Literal remap="tt">Operating systems specific structures</Literal>. In addition to the
2755 expansion of the arrays, I have <Literal remap="tt">"flattened</Literal> the inode to support only
2756 the <Literal remap="tt">Linux</Literal> declaration. It seemed that this one occasion of multiple
2760 <Literal remap="tt">ext2.descriptors</Literal> to accommodate for his needs.
2769 The user interface to <Literal remap="tt">movement</Literal> is the usual <Literal remap="tt">next / prev /
2775 other implementations of <Literal remap="tt">next</Literal> and <Literal remap="tt">prev</Literal>, and they do not save
2781 The <Literal remap="tt">show</Literal> command is overridden here, and provides a lot of additional
2784 Again, the <Literal remap="tt">general show</Literal> is called first, and then the additional
2794 From the inode, a <Literal remap="tt">file</Literal> or a <Literal remap="tt">directory</Literal> can typically be reached.
2797 remap="tt">type_data</Literal> is not overwritten.
2804 An internal global structure which is used by the types <Literal remap="tt">file</Literal>
2805 and <Literal remap="tt">dir</Literal> handling functions is initialized by calling the
2818 The result is that a <Literal remap="tt">settype ext2_inode</Literal> is the only action necessary
2823 Follows the implementation of the inode's <Literal remap="tt">file</Literal> command:
2851 As we can see - We just call <Literal remap="tt">init_file_info</Literal> to get the necessary
2852 information from the inode, and set the type to <Literal remap="tt">file</Literal>. The next call
2853 to <Literal remap="tt">show</Literal>, will dispatch to the <Literal remap="tt">file's show</Literal> implementation.
2867 <Literal remap="tt">file</Literal> - A type which contains no variables, and a special structure is
2897 The <Literal remap="tt">inode_ptr</Literal> will just point to the inode in <Literal remap="tt">type_data</Literal>, which
2899 <Literal remap="tt">setoffset</Literal> command is not internally used. The <Literal remap="tt">buffer</Literal>
2902 <Literal remap="tt">global_block_num</Literal> just contains the current block number.
2912 The global structure of the above type, <Literal remap="tt">file_info</Literal>, is initialized by
2913 <Literal remap="tt">init_file_info</Literal> in <Literal remap="tt">file_com.c</Literal>, which is called by the
2914 <Literal remap="tt">type_ext2_inode___file</Literal> function when the user requests to watch the
2915 file. <Literal remap="tt">It is updated as necessary to provide accurate information as long as
2942 current block is done using <Literal remap="tt">next, prev and offset</Literal> - They just change
2943 <Literal remap="tt">file_info.offset_in_block</Literal>.
2947 Movement between blocks is done using <Literal remap="tt">nextblock, prevblock and block</Literal>.
2949 traced. This is done by <Literal remap="tt">file_block_to_global_block</Literal>, which accepts a
2994 <Literal remap="tt">last_direct, last_indirect, etc</Literal>, contain the last internal block number
2996 <Literal remap="tt">last_direct</Literal>, for example, it is a direct block.
3001 A non-direct block is handled by <Literal remap="tt">return_indirect, return_dindirect and
3004 level functions. For example, <Literal remap="tt">return_dindirect</Literal> is constructed as
3030 The <Literal remap="tt">remember</Literal> command is overridden here and in the <Literal remap="tt">dir</Literal> type -
3041 The <Literal remap="tt">set</Literal> command is overridden, and provides the same functionality
3042 like the usage of the <Literal remap="tt">general set</Literal> command with no type declared. The
3043 <Literal remap="tt">writedata</Literal> is overridden so that we'll write the edited block
3044 (file_info.buffer) and not <Literal remap="tt">type_data</Literal> (Which contains the inode).
3057 same variable of type <Literal remap="tt">struct_file_info</Literal> which is used in the
3058 <Literal remap="tt">file</Literal>, is used here.
3062 The <Literal remap="tt">dir</Literal> type uses all the variables in the above structure, as
3063 opposed to the <Literal remap="tt">file</Literal> type, which didn't use the last ones.
3071 <Literal remap="tt">file</Literal> type, with one main change:
3075 The main function in <Literal remap="tt">dir_com.c</Literal> is <Literal remap="tt">search_dir_entries</Literal>. This
3076 function will <Literal remap="tt">"run"</Literal> on the entire entries in the directory, and will
3079 criterion. It will then signal <Literal remap="tt">search_dir_entries</Literal> whether to
3080 <Literal remap="tt">ABORT</Literal> the search, whether it <Literal remap="tt">FOUND</Literal> the entry it was looking
3081 for, or that the entry is still not found, and we should <Literal remap="tt">CONTINUE</Literal>
3128 It will just <Literal remap="tt">CONTINUE</Literal> until the last entry. The returned structure
3129 (of type <Literal remap="tt">struct_file_info</Literal>) will have its number in the
3130 <Literal remap="tt">dir_entry_num</Literal> field, and this is exactly the required number!
3139 The <Literal remap="tt">cd</Literal> command accepts a relative path, and moves there ...
3146 The path is checked that it is not an absolute path (from <Literal remap="tt">/</Literal>).
3147 If it is, we let the <Literal remap="tt">general cd</Literal> to do the job by calling
3148 directly <Literal remap="tt">type_ext2___cd</Literal>.
3155 For example, cd 1/2/3/4 is divided into <Literal remap="tt">1</Literal> and into
3156 <Literal remap="tt">2/3/4</Literal>.
3163 current directory. We search for it using <Literal remap="tt">search_dir_entries</Literal>,
3164 which accepts the <Literal remap="tt">action_name</Literal> function as the user defined
3171 <Literal remap="tt">search_dir_entries</Literal> will scan the entire entries and will call
3172 our <Literal remap="tt">action_name</Literal> function for each entry. In
3173 <Literal remap="tt">action_name</Literal>, the required name will be checked against the
3174 name of the current entry, and <Literal remap="tt">FOUND</Literal> will be returned when a
3181 If the required entry is found, we dispatch a <Literal remap="tt">remember</Literal>
3182 command to insert the current <Literal remap="tt">inode</Literal> into the object memory.
3183 This is required to easily support <Literal remap="tt">symbolic links</Literal> - If we
3186 inode doesn't have (and can't have, because of <Literal remap="tt">hard links</Literal>) the
3193 We then dispatch a <Literal remap="tt">followinode</Literal> command to reach the inode
3195 change the type to <Literal remap="tt">ext2_inode</Literal> - We are now at an inode, and
3203 dispatch a <Literal remap="tt">dir</Literal> command to "enter the directory", and
3204 recursively call ourself (The type is <Literal remap="tt">dir</Literal> again) by
3205 dispatching a <Literal remap="tt">cd</Literal> command, with the rest of the path as an
3215 <Literal remap="tt">dir</Literal> to get back to the original directory, and we call
3216 ourself again with the <Literal remap="tt">link path/rest of the path</Literal> argument.
3240 into a structure of the <Literal remap="tt">struct_block_bitmap_info</Literal> type:
3255 The <Literal remap="tt">show</Literal> command is overridden, and will show the block as a series of
3257 <Literal remap="tt">entry_num</Literal> variable, declared above, which is just the current block
3259 <Literal remap="tt">next, prev and entry</Literal> commands just change the above variable.
3263 The <Literal remap="tt">allocate and deallocate</Literal> change the specified bits. Nothing
3269 The <Literal remap="tt">inode allocation bitmap</Literal> is treated in much the same fashion, with
3279 While an ext2 filesystem has a size limit of <Literal remap="tt">4 TB</Literal>, EXT2ED currently
3280 <Literal remap="tt">can't</Literal> handle filesystems which are <Literal remap="tt">bigger than 2 GB</Literal>.
3284 This limitation results from my usage of <Literal remap="tt">32 bit long variables</Literal> and
3285 of the <Literal remap="tt">fseek</Literal> filesystem call, which can't seek up to 4 TB.
3289 By looking in the <Literal remap="tt">ext2 library</Literal> source code by <Literal remap="tt">Theodore Ts'o</Literal>,
3290 I discovered the <Literal remap="tt">llseek</Literal> system call which can seek to a
3291 <Literal remap="tt">64 bit unsigned long long</Literal> offset. Correcting the situation is not
3293 appropriate and modify <Literal remap="tt">disk.c</Literal> to use the llseek system call.
3315 EXT2ED has now two levels of abstraction - A <Literal remap="tt">general</Literal> filesystem, and an
3316 <Literal remap="tt">ext2</Literal> filesystem, and the surface is more or less prepared for additions
3339 <Literal remap="tt">ext2.descriptors</Literal> distributed with EXT2ED is a slightly modified
3374 <Literal remap="tt">Technion - Israel's institute of technology</Literal>.
3378 At first, I would like to thank <Literal remap="tt">Avner Lottem</Literal> and <Literal remap="tt">Doctor Ilana
3391 <Literal remap="tt">Remy Card</Literal>
3394 code, and some of the ext2 utilities. <Literal remap="tt">Remy Card</Literal> is also the
3396 Specifically, he is the author of <Literal remap="tt">File Management in the Linux
3397 Kernel</Literal> and of <Literal remap="tt">The Second Extended File System - Current
3405 <Literal remap="tt">Wayne Davison</Literal>
3413 <Literal remap="tt">Stephen Tweedie</Literal>
3416 slides <Literal remap="tt">Optimizations in File Systems</Literal>.
3422 <Literal remap="tt">Theodore Ts'o</Literal>
3425 <Literal remap="tt">libext2fs</Literal> (which I didn't use, simply because I didn't know
3435 Lastly, I would like to thank, of-course, <Literal remap="tt">Linus Torvalds</Literal> and the
3436 <Literal remap="tt">Linux community</Literal> for providing all of us with such a great operating
