mirror of https://github.com/vitalif/e2fsprogs
1189 lines
41 KiB
Plaintext
1189 lines
41 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<!-- EXT2ED user's guide -->
|
|
<!-- First written: July 22 1995 -->
|
|
<!-- Last updated: August 3 1995 -->
|
|
<!-- This document is written Using the Linux documentation project Linuxdoc-SGML DTD -->
|
|
|
|
<article>
|
|
|
|
<title>EXT2ED - The Extended-2 filesystem editor - User's guide
|
|
<author>Gadi Oxman, tgud@tochnapc2.technion.ac.il
|
|
<date>v0.1, August 3 1995
|
|
<abstract>
|
|
This is only the initial version of this document. It may be unclear at
|
|
some places. Please send me feedback with anything regarding to it.
|
|
</abstract>
|
|
<toc>
|
|
|
|
<!-- Begin of document -->
|
|
|
|
<sect>About EXT2ED documentation
|
|
<p>
|
|
|
|
The EXT2ED documentation consists of three parts:
|
|
<itemize>
|
|
<item> The ext2 filesystem overview.
|
|
<item> The EXT2ED user's guide.
|
|
<item> The EXT2ED design and implementation.
|
|
</itemize>
|
|
|
|
If you intend to used EXT2ED, I strongly suggest that you would be familiar
|
|
with the material presented in the <tt>ext2 filesystem overview</> as well.
|
|
|
|
If you also intend to browse and modify the source code, I suggest that you
|
|
will also read the article <tt>The EXT2ED design and implementation</>, as it
|
|
provides a general overview of the structure of my source code.
|
|
|
|
<sect>Introduction
|
|
|
|
<p>
|
|
EXT2ED is a "disk editor" for the ext2 filesystem. Its purpose is to show
|
|
you the internal structures of the ext2 filesystem in an rather intuitive
|
|
and logical way, so that it will be easier to "travel" between the various
|
|
internal filesystem structures.
|
|
|
|
<sect>Basic concepts in EXT2ED
|
|
|
|
<p>
|
|
Two basic concepts in EXT2ED are <tt>commands</> and <tt>types</>.
|
|
|
|
EXT2ED is object-oriented in the sense that it defines objects in the
|
|
filesystem, like a <tt>super-block</> or a <tt>directory</>. An object is
|
|
something which "knows" how to handle some aspect of the filesystem.
|
|
|
|
Your interaction with EXT2ED is done through <tt>commands</> which EXT2ED
|
|
accepts. There are three levels of commands:
|
|
<itemize>
|
|
<item> General Commands
|
|
<item> Extended-2 Filesystem general commands
|
|
<item> Type specific commands
|
|
</itemize>
|
|
The General commands are always available.
|
|
|
|
The ext2 general commands are available only when editing an ext2 filesystem.
|
|
|
|
The Type specific commands are available when editing a specific object in the
|
|
filesystem. Each object typically comes with its own set of internal
|
|
variables, and its own set of commands, which are fine tuned handle the
|
|
corresponding structure in the filesystem.
|
|
<sect>Running EXT2ED
|
|
<p>
|
|
Running EXT2ED is as simple as typing <tt>ext2ed</> from the shell prompt.
|
|
There are no command line switches.
|
|
|
|
When first run, EXT2ED parses its configuration file, <tt>ext2ed.conf</>.
|
|
This file must exist.
|
|
|
|
When the configuration file processing is done, EXT2ED screen should appear
|
|
on the screen, with the command prompt <tt>ext2ed></> displayed.
|
|
|
|
<sect>EXT2ED user interface
|
|
|
|
<p>
|
|
EXT2ED uses the <em>ncurses</> library for screen management. Your screen
|
|
will be divided into four parts, from top to bottom:
|
|
<itemize>
|
|
<item> Title window
|
|
<item> Status window
|
|
<item> Main editing window
|
|
<item> Command window
|
|
</itemize>
|
|
The title window just displays the current version of EXT2ED.
|
|
|
|
The status window will display various information regarding the state of
|
|
the editing at this point.
|
|
|
|
The main editing window is the place at which the actual data will be shown.
|
|
Almost every command will cause some display at this window. This window, as
|
|
opposed to the three others, is of variable length - You always look at one
|
|
page of it. The current page and the total numbers of pages at this moment
|
|
is displayed at the status window. Moving between pages is done by the use
|
|
of the <tt>pgdn</> and <tt>pgup</> commands.
|
|
|
|
The command window is at the bottom of the screen. It always displays a
|
|
command prompt <tt>ext2ed></> and allows you to type a command. Feedback
|
|
about the commands entered is displayed to this window also.
|
|
|
|
EXT2ED uses the <em>readline</> library while processing a command line. All
|
|
the usual editing keys are available. Each entered command is placed into a
|
|
history of commands, and can be recalled later. Command Completion is also
|
|
supported - Just start to type a command, and press the completion key.
|
|
|
|
Pressing <tt>enter</> at the command window, without entering a command,
|
|
recalls the last command. This is useful when moving between close entries,
|
|
in the <tt>next</> command, for example.
|
|
|
|
<sect>Getting started
|
|
|
|
<p>
|
|
|
|
<sect1>A few precautions
|
|
|
|
<p>
|
|
|
|
EXT2ED is a tool for filesystem <tt>editing</>. As such, it can be
|
|
<tt>dangerous</>. The summary to the subsections below is that
|
|
<tt>You must know what you are doing</>.
|
|
|
|
<sect2><label id="mounted_ref">A mounted filesystem
|
|
|
|
<p>
|
|
|
|
EXT2ED is not designed to work on a mounted filesystem - It is complicated
|
|
enough as it is; I didn't even try to think of handling the various race
|
|
conditions. As such, please respect the following advice:
|
|
|
|
<tt>Do not use EXT2ED on a mounted filesystem !</>
|
|
|
|
EXT2ED will not allow write access to a mounted filesystem. Although it is
|
|
fairly easy to change EXT2ED so that it will be allowed, I hereby request
|
|
again- EXT2ED is not designed for that action, and will most likely corrupt
|
|
data if used that way. Please don't do that.
|
|
|
|
Concerning read access, I chose to leave the decision for the user through
|
|
the configuration file option <tt>AllowMountedRead</>. Although read access
|
|
on a mounted partition will not do any damage to the filesystem, the data
|
|
displayed to you will not be reliable, and showing you incorrect information
|
|
may be as bad as corrupting the filesystem. However, you may still wish to
|
|
do that.
|
|
|
|
<sect2>Write access
|
|
|
|
<p>
|
|
|
|
Considering the obvious sensitivity of the subject, I took the following
|
|
actions:
|
|
|
|
<enum>
|
|
<item> EXT2ED will always start with a read-only access. Write access mode
|
|
needs to be specifically entered by the <tt>enablewrite</> command.
|
|
Until this is done, no write will be allowed. Write access can be
|
|
disabled at any time with <tt>disablewrite</>. When
|
|
<tt>enablewrite</> is issued, the device is reopened in read-write
|
|
mode. Needless to say, the device permissions should allow that.
|
|
<item> As a second level of protection, you can disallow write access in
|
|
the configuration file by using the <tt>AllowChanges off</>
|
|
configuration option. In this case, the <tt>enablewrite</> command
|
|
will be refused.
|
|
<item> When write access is enabled, the data will never change
|
|
immediately. Rather, a specific <tt>writedata</> command is needed
|
|
to update the object in the disk with the changed object in memory.
|
|
<item> In addition, A logging option is provided through the configuration
|
|
file options <tt>LogChanges</> and <tt>LogFile</>. With logging
|
|
enabled, each change to the disk will be logged at a very primitive
|
|
level - A hex dump of the original data and of the new written data.
|
|
The log file will be a text file which is easily readable, and you
|
|
can make use of it to undo any changes which you made (EXT2ED doesn't
|
|
make use of the log file for that purpose, it just logs the changes).
|
|
</enum>
|
|
Please remember that this is only the initial release of EXT2ED, and it is
|
|
not very much tested - It is reasonable to assume that <tt>there are
|
|
bugs</>.
|
|
However, the logging option above can offer protection even from this
|
|
unfortunate case. Therefor, I highly recommend that at least when first
|
|
working with EXT2ED, the logging option will be enabled, despite the disk
|
|
space which it consumes.
|
|
|
|
<sect1><label id="help_ref">The help command
|
|
|
|
<p>
|
|
|
|
When loaded, EXT2ED will show a short help screen. This help screen can
|
|
always be retrieved by the command <tt>help</>. The help screen displays a
|
|
list of all the commands which are available at this point. At startup, only
|
|
the <tt>General commands</> are available.
|
|
This will change with time, since each object has its own commands. Thus,
|
|
commands which are available now may not be available later.
|
|
Using <tt>help</> <em>command</> will display additional information about
|
|
the specific command <em>command</>.
|
|
|
|
<sect1><label id="setdevice_ref">The setdevice command
|
|
|
|
<p>
|
|
|
|
The first command that is usually entered to EXT2ED is the <tt>setdevice</>
|
|
command. This command simply tells EXT2ED on which device the filesystem is
|
|
present. For example, suppose my ext2 filesystem is on the first partition
|
|
of my ide disk. The command will be:
|
|
<tscreen><verb>
|
|
setdevice /dev/hda1
|
|
</verb></tscreen>
|
|
The following actions will take place in the following order:
|
|
<enum>
|
|
<item> EXT2ED will check if the partition is mounted.
|
|
If the partition is mounted (<tt>highly not recommended</>),
|
|
the accept/reject behavior will be decided by the configuration
|
|
file. Cross reference section <ref id="mounted_ref">.
|
|
<item> The specified device will be opened in read-only mode. The
|
|
permissions of the device should be set in a way that allows
|
|
you to open the device for read access.
|
|
<item> Autodetection of an ext2 filesystem will be made by searching for
|
|
the ext2 magic number in the main superblock.
|
|
<item> In the case of a successful recognition of an ext2 filesystem, the
|
|
ext2 filesystem specific commands and the ext2 specific object
|
|
definitions will be registered. The object definitions will be read
|
|
at run time from a file specified by the configuration file.
|
|
|
|
In case of a corrupted ext2 filesystem, it is quite possible that
|
|
the main superblock is damaged and autodetection will fail. In that
|
|
case, use the configuration option <tt>ForceExt2 on</>. This is not
|
|
the default case since EXT2ED can be used at a lower level to edit a
|
|
non-ext2 filesystem.
|
|
<item> In a case of a successful autodetection, essential information about
|
|
the filesystem such as the block size will be read from the
|
|
superblock, unless the used overrides this behavior with an
|
|
configuration option (not recommended). In that case, the parameters
|
|
will be read from the configuration file.
|
|
|
|
In a case of an autodetection failure, the essential parameters
|
|
will be read from the configuration file.
|
|
</enum>
|
|
Assuming that you are editing an ext2 filesystem and that everything goes
|
|
well, you will notice that additional commands are now available in the help
|
|
screen, under the section <tt>ext2 filesystem general commands</>. In
|
|
addition, EXT2ED now recognizes a few objects which are essential to the
|
|
editing of an ext2 filesystem.
|
|
|
|
<sect>Two levels of usage
|
|
|
|
<p>
|
|
|
|
<sect1>Low level usage
|
|
|
|
<p>
|
|
This section explains what EXT2ED provides even when not editing an ext2
|
|
filesystem.
|
|
|
|
Even at this level, EXT2ED is more than just a hex editor. It still allows
|
|
definition of objects and variables in run time through a user file,
|
|
although of-course the objects will not have special fine tuned functions
|
|
connected to them. EXT2ED will allow you to move in the filesystem using
|
|
<tt>setoffset</>, and to apply an object definition on a specific place
|
|
using <tt>settype</> <em>type</>. From this point and on, the object will
|
|
be shown <tt>in its native form</> - You will see a list of the
|
|
variables rather than just a hex dump, and you will be able to change each
|
|
variable in the intuitive form <tt>set variable=value</>.
|
|
|
|
To define objects, use the configuration option <tt>AlternateDescriptors</>.
|
|
|
|
There are now two forms of editing:
|
|
<itemize>
|
|
<item> Editing without a type. In this case, the disk block will be shown
|
|
as a text+hex dump, and you will be able to move along and change it.
|
|
<item> Editing with a type. In this case, the object's variables will be
|
|
shown, and you will be able to change each variable in its native form.
|
|
</itemize>
|
|
|
|
<sect1>High level usage
|
|
|
|
<p>
|
|
EXT2ED was designed for the editing of the ext2 filesystem. As such, it
|
|
"understands" the filesystem structure to some extent. Each object now has
|
|
special fine tuned 'C' functions connected to it, which knows how to display
|
|
it in an intuitive form, and how the object fits in the general design of
|
|
the ext2 filesystem. It is of-course much easier to use this type of
|
|
editing. For example:
|
|
<tscreen>
|
|
Issue <em>group 2</> to look at the main copy of the third group block
|
|
descriptor. With <em>gocopy 1</> you can move to its first backup copy,
|
|
and with <em>inode</> you can start editing the inode table of the above
|
|
group block. From here, if the inode corresponds to a file, you can
|
|
use <em>file</> to edit the file in a "continuous" way, using
|
|
<em>nextblock</> to pass to its next block, letting EXT2ED following by
|
|
itself the direct blocks, indirect blocks, ..., while still preserving the
|
|
actual view of the exact block usage of the file.
|
|
</tscreen>
|
|
The point is that the "tour" of the filesystem will now be synchronic rather
|
|
than asynchronic - Each object has the "links" to pass between connected
|
|
logical structures, and special fine-tuned functions to deal with it.
|
|
|
|
<sect>General commands
|
|
|
|
<p>
|
|
I will now start with a systematic explanation of the general commands.
|
|
Please feel free to experiment, but take care when using the
|
|
<tt>enablewrite</> command.
|
|
|
|
Whenever a command syntax is specified, arguments which are optional are
|
|
enclosed with square brackets.
|
|
|
|
Please note that in EXT2ED, each command can be overridden by a specific
|
|
object to provide special fine-tuned functionality. In general, I was
|
|
attempting to preserve the similarity between those functions, which are
|
|
accessible by the same name.
|
|
|
|
<sect1><label id="disablewrite_ref">disablewrite
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: disablewrite
|
|
</verb></tscreen>
|
|
<tt>disablewrite</> is used to reopen the device with read-only access. When
|
|
first running EXT2ED, the device is opened in read-only mode, and an
|
|
explicit <tt>enablewrite</> is required for write access. When finishing
|
|
with changing, a <tt>disablewrite</> is recommended for safety. Cross
|
|
reference section <ref id="disablewrite_ref">.
|
|
|
|
<sect1><label id="enablewrite_ref">enablewrite
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: enablewrite
|
|
</verb></tscreen>
|
|
<tt>enablewrite</> is used to reopen the device with read-write access.
|
|
When first running EXT2ED, the device is opened in read-only mode, and an
|
|
explicit <tt>enablewrite</> is required for write access.
|
|
<tt>enablewrite</> will fail if write access is disabled from the
|
|
configuration file by the <tt>AllowChanges off</> configuration option.
|
|
Even after <tt>enablewrite</>, an explicit <tt>writedata</>
|
|
is required to actually write the new data to the disk.
|
|
When finishing with changing, a <tt>disablewrite</> is recommended for safety.
|
|
Cross reference section <ref id="enablewrite_ref">.
|
|
|
|
<sect1>help
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: help [command]
|
|
</verb></tscreen>
|
|
The <tt>help</> command is described at section <ref id="help_ref">.
|
|
|
|
<sect1><label id="next_ref">next
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: next [number]
|
|
</verb></tscreen>
|
|
This section describes the <em>general command</> <tt>next</>. <tt>next</>
|
|
is overridden by several types in EXT2ED, to provide fine-tuned
|
|
functionality.
|
|
|
|
The <tt>next general command</> behavior is depended on whether you are editing a
|
|
specific object, or none.
|
|
|
|
<itemize>
|
|
<item> In the case where Type is <tt>none</> (The current type is showed
|
|
on the status window by the <tt>show</> command), <tt>next</>
|
|
passes to the next <em>number</> bytes in the current edited block.
|
|
If <em>number</> is not specified, <em>number=1</> is assumed.
|
|
<item> In the case where Type is defined, the <tt>next</> commands assumes
|
|
that you are editing an array of objects of that type, and the
|
|
<tt>next</> command will just pass to the next entry in the array.
|
|
If <em>number</> is defined, it will pass <em>number</> entries
|
|
ahead.
|
|
</itemize>
|
|
|
|
<sect1><label id="pgdn_ref">pgdn
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: pgdn
|
|
</verb></tscreen>
|
|
Usually the edited data doesn't fit into the visible main window. In this
|
|
case, the status window will indicate that there is more to see "below" by
|
|
the message <tt>Page x of y</>. This means that there are <em>y</> pages
|
|
total, and you are currently viewing the <em>x</> page. With the <tt>pgdn</>
|
|
command, you can pass to the next available page.
|
|
|
|
<sect1>pgup
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: pgup
|
|
</verb></tscreen>
|
|
|
|
<tt>pgup</> is the opposite of <tt>pgdn</> - It will pass to the previous
|
|
page. Cross reference section <ref id="pgdn_ref">.
|
|
|
|
<sect1>prev
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: prev [number]
|
|
</verb></tscreen>
|
|
|
|
<tt>prev</> is the opposite of <tt>next</>. Cross reference section
|
|
<ref id="next_ref">.
|
|
|
|
<sect1><label id="recall_ref">recall
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: recall object
|
|
</verb></tscreen>
|
|
<tt>recall</> is the opposite of <tt>remember</>. It will place you at the
|
|
place you where when saving the object position and type information. Cross
|
|
reference section <ref id="remember_ref">.
|
|
|
|
<sect1>redraw
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: redraw
|
|
</verb></tscreen>
|
|
Sometimes the screen display gets corrupted. I still have problems with
|
|
this. The <tt>redraw</> command simply redraws the entire display screen.
|
|
|
|
<sect1><label id="remember_ref">remember
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: remember object
|
|
</verb></tscreen>
|
|
EXT2ED provides you <tt>memory</> of objects; While editing, you may reach an
|
|
object which you will like to return to later. The <tt>remember</> command
|
|
will store in memory the current place and type of the object. You can
|
|
return to the object by using the <tt>recall</> command. Cross reference
|
|
section <ref id="recall_ref">.
|
|
|
|
<tt>Note:</>
|
|
<itemize>
|
|
<item> When remembering a <tt>file</> or a <tt>directory</>, the
|
|
corresponding inode will be saved in memory. The basic reason is that
|
|
the inode is essential for finding the blocks of the file or the
|
|
directory.
|
|
</itemize>
|
|
|
|
<sect1>set
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: set [text || hex] arg1 [arg2 arg3 ...]
|
|
|
|
or
|
|
|
|
Syntax: set variable=value
|
|
</verb></tscreen>
|
|
The <tt>set</> command is used to modify the current data.
|
|
The <tt>set general command</> behavior is depended on whether you are editing a
|
|
specific object, or none.
|
|
|
|
<itemize>
|
|
<item> In the case where Type is <tt>none</>, the first syntax should be
|
|
used. The set command affects the data starting at the current
|
|
highlighted position in the edited block.
|
|
<itemize>
|
|
<item> When using the <tt>set hex</> command, a list of
|
|
hexadecimal bytes should follow.
|
|
<item> When using the <tt>set text</> command, it should be followed
|
|
by a text string.
|
|
</itemize>
|
|
Examples:
|
|
<tscreen><verb>
|
|
set hex 09 0a 0b 0c 0d 0e 0f
|
|
set text Linux is just great !
|
|
</verb></tscreen>
|
|
<item> In the case where Type is defined, the second syntax should be used.
|
|
The set commands just sets the variable <em>variable</> with the
|
|
value <em>value</>.
|
|
</itemize>
|
|
In any case, the data is only changed in memory. For an actual update to the
|
|
disk, use the <tt>writedata</> command.
|
|
|
|
<sect1>setdevice
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: setdevice device
|
|
</verb></tscreen>
|
|
The <tt>setdevice</> command is described at section <ref id="setdevice_ref">.
|
|
|
|
<sect1>setoffset
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: setoffset [block || type] [+|-]offset
|
|
</verb></tscreen>
|
|
The <tt>setoffset</> command is used to move asynchronically inside the file
|
|
system. It is considered a low level command, and usually should not be used
|
|
when editing an ext2 filesystem, simply because movement is better
|
|
utilized through the specific ext2 commands.
|
|
|
|
The <tt>offset</> is in bytes, and meanwhile should be positive and smaller
|
|
than 2GB.
|
|
|
|
Use of the <tt>block</> modifier changes the counting unit to block.
|
|
|
|
Use of the <tt>+ or -</> modifiers signals that the offset is relative to
|
|
the current position.
|
|
|
|
use of the <tt>type</> modifier is allowed only with relative offset. This
|
|
modifier will multiply the offset by the size of the current type.
|
|
|
|
<sect1>settype
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: settype type || [none | hex]
|
|
</verb></tscreen>
|
|
The <tt>settype</> command is used to move apply the object definitions of
|
|
the type <em>type</> on the current position. It is considered a low level
|
|
command and usually should not be used when editing an ext2 filesystem since
|
|
EXT2ED provides better tools. It is of-course very useful when editing a
|
|
non-ext2 filesystem and using user-defined objects.
|
|
|
|
When <em>type</> is <em>hex</> or <em>none</>, the data will be displayed as
|
|
a hex and text dump.
|
|
|
|
<sect1>show
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: show
|
|
</verb></tscreen>
|
|
The <tt>show</> command will show the data of the current object at the
|
|
current position on the main display window. It will also update the status
|
|
window with type specific information. It may be necessary to use
|
|
<tt>pgdn</> and <tt>pgup</> to view the entire data.
|
|
|
|
<sect1>writedata
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: writedata
|
|
</verb></tscreen>
|
|
The <tt>writedata</> command will update the disk with the object data that
|
|
is currently in memory. This is the point at which actual change is made to
|
|
the filesystem. Without this command, the edited data will not have any
|
|
effect. Write access should be allowed for a successful update.
|
|
|
|
<sect>Editing an ext2 filesystem
|
|
<p>
|
|
|
|
In order to edit an ext2 filesystem, you should, of course, know the structure
|
|
of the ext2 filesystem. If you feel that you lack some knowledge in this
|
|
area, I suggest that you do some of the following:
|
|
<itemize>
|
|
<item> Read the supplied ext2 technical information. I tried to summarize
|
|
the basic information which is needed to get you started.
|
|
<item> Get the slides that Remy Card (The author of the ext2 filesystem)
|
|
prepared concerning the ext2 filesystem.
|
|
<item> Read the kernel sources.
|
|
</itemize>
|
|
At this point, you should be familiar with the following terms:
|
|
<tt>block, inode, superblock, block groups, block allocation bitmap, inode
|
|
allocation bitmap, group descriptors, file, directory.</>Most of the above
|
|
are objects in EXT2ED.
|
|
|
|
When editing an ext2 filesystem it is recommended that you use the ext2
|
|
specific commands, rather then the general commands <tt>setoffset</> and
|
|
<tt>settype</>, mainly because:
|
|
<enum>
|
|
<item> In most cases it will be unreliable, and will display incorrect
|
|
information.
|
|
|
|
Sometimes in order to edit an object, EXT2ED needs the information
|
|
of some other related objects. For example, when editing a
|
|
directory, EXT2ED needs access to the inode of the edited directory.
|
|
Simply setting the type to a directory <tt>will be unreliable</>,
|
|
since the object assumes that you passed through its inode to reach
|
|
it, and expects this information, which isn't initialized if you
|
|
directly set the type to a directory.
|
|
<item> EXT2ED offers far better tools for handling the ext2 filesystem
|
|
using the ext2 specific commands.
|
|
</enum>
|
|
|
|
<sect>ext2 general commands
|
|
<p>
|
|
|
|
The <tt>ext2 general commands</> are available only when you are editing an
|
|
ext2 filesystem. They are <tt>general</> in the sense that they are not
|
|
specific to some object, and can be invoked anytime.
|
|
|
|
<sect1><label id="general_superblock">super
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: super
|
|
</verb></tscreen>
|
|
The <tt>super</> command will "bring you" to the main superblock copy. It
|
|
will automatically set the object type to <tt>ext2_super_block</>. Then you
|
|
will be able to view and edit the superblock. When you are in the
|
|
superblock, other commands will be available.
|
|
|
|
<sect1>group
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: group [number]
|
|
</verb></tscreen>
|
|
The <tt>group</> command will "bring you" to the main copy of the
|
|
<em>number</> group descriptor. It will automatically set the object type to
|
|
<tt>ext2_group_desc</>. Then you will be able to view and edit the group
|
|
descriptor entry. When you are there, other commands will be available.
|
|
|
|
<sect1>cd
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: cd path
|
|
</verb></tscreen>
|
|
The <tt>cd</> command will let you travel in the filesystem in the nice way
|
|
that the mounted filesystem would have let you.
|
|
|
|
The <tt>cd</> command is a complicated command. Although it may sound
|
|
simple at first, an implementation of a typical cd requires passing through
|
|
the group descriptors, inodes, directory entries, etc. For example:
|
|
|
|
The innocent cd /usr command can be done by using more primitive
|
|
EXT2ED commands in the following way (It is implemented exactly this way):
|
|
<enum>
|
|
<item> Using <tt>group 0</> to go to the first group descriptor.
|
|
<item> Using <tt>inode</> to get to the Bad blocks inode.
|
|
<item> Using <tt>next</> to pass to the root directory inode.
|
|
<item> Using <tt>dir</> to see the directory.
|
|
<item> Using <tt>next</> until we find the directory usr.
|
|
<item> Using <tt>followinode</> to pass to the inode corresponding to usr.
|
|
<item> Using <tt>dir</> to see the directory of /usr.
|
|
</enum>
|
|
And those commands aren't that primitive; For example, the tracing of the
|
|
blocks which belong to the root directory is done automatically by the dir
|
|
command behind the scenes, and the followinode command will automatically
|
|
"run" to the correct group descriptor in order to find the required inode.
|
|
|
|
The path to the <tt>general cd</> command needs to be a full pathname -
|
|
Starting from <tt>/</>. The <tt>cd</> command stops at the last reachable
|
|
point, which can be a directory entry, in which case the type will be set to
|
|
<tt>dir</>, or an inode, in which case the type will be set to
|
|
<tt>ext2_inode</>. Symbolic links (Only fast symbolic links, meanwhile) are
|
|
automatically followed (if they are not across filesystems, of-course). If
|
|
the type is set to <tt>dir</>, you can use a path relative to the
|
|
"current directory".
|
|
|
|
<sect>The superblock
|
|
<p>
|
|
The superblock can always be reached by the ext2 general command
|
|
<tt>super</>. Cross reference section <ref id="general_superblock">.
|
|
|
|
The status window will show you which copy of the superblock copies you are
|
|
currently editing.
|
|
|
|
The main data window will show you the values of the various superblock
|
|
variables, along with some interpretation of the values.
|
|
|
|
Data can be changed with the <tt>set</> and <tt>writedata</> commands.
|
|
<tscreen><verb>
|
|
For example, set s_r_blocks_count=1400 will reserve 1400 blocks for root.
|
|
</verb></tscreen>
|
|
|
|
<sect1>gocopy
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: gocopy number
|
|
</verb></tscreen>
|
|
The <tt>gocopy</> command will "bring you" to the backup copy <em>number</>
|
|
of the superblock copies. <tt>gocopy 0</>, for example, will bring you to
|
|
the main copy.
|
|
|
|
<sect1>setactivecopy
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: setactivecopy
|
|
</verb></tscreen>
|
|
The <tt>setactivecopy</> command will copy the contents of the current
|
|
superblock copy onto the contents of the main copy. It will also switch to
|
|
editing of the main copy. No actual data is written to disk, of-course,
|
|
until you issue the <tt>writedata</> command.
|
|
|
|
<sect>The group descriptors
|
|
<p>
|
|
The group descriptors can be edited by the <tt>group</> command.
|
|
|
|
The status window will indicate the current group descriptor, the total
|
|
number of group descriptors (and hence of group blocks), and the backup copy
|
|
number.
|
|
|
|
The main data window will just show you the values of the various variables.
|
|
|
|
Basically, you can use the <tt>next</> and <tt>prev</> commands, along with the
|
|
<tt>set</> command, to modify the group descriptors.
|
|
|
|
The group descriptors object is a junction, from which you can reach:
|
|
<itemize>
|
|
<item> The inode table of the corresponding block group (the <tt>inode</>
|
|
command)
|
|
<item> The block allocation bitmap (the <tt>blockbitmap</> command)
|
|
<item> The inode allocation bitmap (the <tt>inodebitmap</> command)
|
|
</itemize>
|
|
|
|
<sect1>blockbitmap
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: blockbitmap
|
|
</verb></tscreen>
|
|
The <tt>blockbitmap</> command will let you edit the block bitmap allocation
|
|
block of the current group block.
|
|
|
|
<sect1>entry
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: entry number
|
|
</verb></tscreen>
|
|
The <tt>entry</> command will move you to the <em>number</> group descriptor in the
|
|
group descriptors table.
|
|
|
|
<sect1>inode
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: inode
|
|
</verb></tscreen>
|
|
The <tt>inode</> command will pass you to the first inode in the current
|
|
group block.
|
|
|
|
<sect1>inodebitmap
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: inodebitmap
|
|
</verb></tscreen>
|
|
The <tt>inodebitmap</> command will let you edit the inode bitmap allocation
|
|
block of the current group block.
|
|
|
|
<sect1>next
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: next [number]
|
|
</verb></tscreen>
|
|
The <tt>next</> command will pass to the next <em>number</> group
|
|
descriptor. If <em>number</> is omitted, <em>number=1</> is assumed.
|
|
|
|
<sect1>prev
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: prev [number]
|
|
</verb></tscreen>
|
|
The <tt>prev</> command will pass to the previous <em>number</> group
|
|
descriptor. If <em>number</> is omitted, <em>number=1</> is assumed.
|
|
|
|
<sect1>setactivecopy
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: setactivecopy
|
|
</verb></tscreen>
|
|
The <tt>setactivecopy</> command copies the contents of the current group
|
|
descriptor, to its main copy. The updated main copy will then be shown. No
|
|
actual change is made to the disk until you issue the <tt>writedata</>
|
|
command.
|
|
|
|
<sect>The inode
|
|
<p>
|
|
An inode can be reached by the following two ways:
|
|
<itemize>
|
|
<item> Using <tt>inode</> from the corresponding group descriptor.
|
|
<item> Using <tt>followinode</> from a directory entry.
|
|
<item> Using the <tt>cd</> command with the pathname to the file.
|
|
|
|
For example, <tt>cd /usr/src/ext2ed/ext2ed.h</>
|
|
</itemize>
|
|
|
|
The status window will indicate:
|
|
<itemize>
|
|
<item> The current global inode number.
|
|
<item> The total total number of inodes.
|
|
<item> On which block group the inode is allocated.
|
|
<item> The total number of inodes in this group block.
|
|
<item> The index of the current inode in the current group block.
|
|
<item> The type of the inode (file, directory, special, etc).
|
|
</itemize>
|
|
|
|
The main data window, in addition to the list of variables, will contain
|
|
some interpretations on the right side.
|
|
|
|
If the inode corresponds to a file, you can use the <tt>file</> command to
|
|
edit the file.
|
|
|
|
If the inode is an inode of a directory, you can use the <tt>dir</> command
|
|
to edit the directory.
|
|
|
|
<sect1>dir
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: dir
|
|
</verb></tscreen>
|
|
If the inode mode corresponds to a directory (shown on the status window),
|
|
you can enter directory mode editing by using <tt>dir</>.
|
|
|
|
<sect1>entry
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: entry number
|
|
</verb></tscreen>
|
|
The <tt>entry</> command will move you to the <em>number</> inode in the
|
|
current inode table.
|
|
|
|
<sect1>file
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: file
|
|
</verb></tscreen>
|
|
If the inode mode corresponds to a file (shown on the status window),
|
|
you can enter file mode editing by using <tt>file</>.
|
|
|
|
<sect1>group
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: group
|
|
</verb></tscreen>
|
|
The <tt>group</> command is used to go to the group descriptor of the
|
|
current group block.
|
|
|
|
<sect1>next
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: next [number]
|
|
</verb></tscreen>
|
|
The <tt>next</> command will pass to the next <em>number</> inode.
|
|
If <em>number</> is omitted, <em>number=1</> is assumed.
|
|
|
|
<sect1>prev
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: prev [number]
|
|
</verb></tscreen>
|
|
The <tt>prev</> command will pass to the previous <em>number</> inode.
|
|
If <em>number</> is omitted, <em>number=1</> is assumed.
|
|
|
|
<sect>The file
|
|
<p>
|
|
When editing a file, EXT2ED offers you a both a continuous and a true
|
|
fragmented view of the file - The file is still shown block by block with
|
|
the true block number at each stage and EXT2ED offers you commands which
|
|
allow you to move between the <tt>file blocks</>, while finding the
|
|
allocated blocks by using the inode information behind the scenes.
|
|
|
|
Aside from this, the editing is just a <tt>hex editing</> - You move the
|
|
cursor in the current block of the file by using <tt>next</> and
|
|
<tt>prev</>, move between blocks by <tt>nextblock</> and <tt>prevblock</>,
|
|
and make changes by the <tt>set</> command. Note that the set command is
|
|
overridden here - There are no variables. The <tt>writedata</> command will
|
|
update the current block to the disk.
|
|
|
|
Reaching a file can be done by using the <tt>file</> command from its inode.
|
|
The <tt>inode</> can be reached by any other means, for example, by the
|
|
<tt>cd</> command, if you know the file name.
|
|
|
|
The status window will indicate:
|
|
<itemize>
|
|
<item> The global block number.
|
|
<item> The internal file block number.
|
|
<item> The file offset.
|
|
<item> The file size.
|
|
<item> The file inode number.
|
|
<item> The indirection level - Whether it is a direct block (0), indirect
|
|
(1), etc.
|
|
</itemize>
|
|
|
|
The main data window will display the file either in hex mode or in text
|
|
mode, select-able by the <tt>display</> command.
|
|
|
|
In hex mode, EXT2ED will display offsets in the current block, along with a
|
|
text and hex dump of the current block.
|
|
|
|
In either case the <tt>current place</> will be highlighted. In the hex mode
|
|
it will be always highlighted, while in the text mode it will be highlighted
|
|
if the character is display-able.
|
|
|
|
<sect1>block
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: block block_num
|
|
</verb></tscreen>
|
|
The <tt>block</> command is used to move inside the file. The
|
|
<em>block_num</> argument is the requested internal file block number. A
|
|
value of 0 will reach the beginning of the file.
|
|
|
|
<sect1>display
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: display [text || hex]
|
|
</verb></tscreen>
|
|
The <tt>display</> command changes the display mode of the file. <tt>display
|
|
hex</> will switch to <tt>hex mode</>, while <tt>display text</> will switch
|
|
to text mode. The default mode when no <tt>display</> command is issued is
|
|
<tt>hex mode</>.
|
|
|
|
<sect1>inode
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: inode
|
|
</verb></tscreen>
|
|
The <tt>inode</> command will return to the inode of the current file.
|
|
|
|
<sect1>next
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: next [num]
|
|
</verb></tscreen>
|
|
The <tt>next</> command will pass to the next byte in the file. If
|
|
<em>num</> is supplied, it will pass to the next <em>num</> bytes.
|
|
|
|
<sect1>nextblock
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: nextblock [num]
|
|
</verb></tscreen>
|
|
The <tt>nextblock</> command will pass to the next block in the file. If
|
|
<em>num</> is supplied, it will pass to the next <em>num</> blocks.
|
|
|
|
<sect1>prev
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: prev [num]
|
|
</verb></tscreen>
|
|
The <tt>prev</> command will pass to the previous byte in the file. If
|
|
<em>num</> is supplied, it will pass to the previous <em>num</> bytes.
|
|
|
|
<sect1>prevblock
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: prevblock [num]
|
|
</verb></tscreen>
|
|
The <tt>nextblock</> command will pass to the previous block in the file. If
|
|
<em>num</> is supplied, it will pass to the previous <em>num</> blocks.
|
|
|
|
<sect1>offset
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: offset file_offset
|
|
</verb></tscreen>
|
|
The <tt>offset</> command will move to the specified offset in the file.
|
|
|
|
<sect1>set
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: set [text || hex] arg1 [arg2 arg3 ...]
|
|
</verb></tscreen>
|
|
The <tt>file set</> command is working like the <tt>general set command</>,
|
|
with <tt>type=none</>. There are no variables.
|
|
|
|
<sect1>writedata
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: writedata
|
|
</verb></tscreen>
|
|
The <tt>writedata</> command will update the current file block in the disk.
|
|
|
|
<sect>The directory
|
|
<p>
|
|
When editing a file, EXT2ED analyzes for you both the allocation blocks of
|
|
the directory entries, and the directory entries.
|
|
|
|
Each directory entry is displayed on one row. You can move the highlighted
|
|
entry with the usual <tt>next</> and <tt>prev</> commands, and "dive in"
|
|
with the <tt>followinode</> command.
|
|
|
|
The status window will indicate:
|
|
<itemize>
|
|
<item> The directory entry number.
|
|
<item> The total number of directory entries in this directory.
|
|
<item> The current global block number.
|
|
<item> The current offset in the entire directory - When viewing the
|
|
directory as a continuous file.
|
|
<item> The inode number of the directory itself.
|
|
<item> The indirection level - Whether it is a direct block (0), indirect
|
|
(1), etc.
|
|
</itemize>
|
|
|
|
<sect1>cd
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: cd [path]
|
|
</verb></tscreen>
|
|
The <tt>cd</> command is used in the usual meaning, like the global cd
|
|
command.
|
|
<itemize>
|
|
<item> If <em>path</> is not specified, the current directory entry is
|
|
followed.
|
|
<item> <em>path</> can be relative to the current directory.
|
|
<item> <em>path</> can also end up in a file, in which case the file inode
|
|
will be reached.
|
|
<item> Symbolic link (fast only, meanwhile) is automatically followed.
|
|
</itemize>
|
|
|
|
<sect1>entry
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: entry [entry_num]
|
|
</verb></tscreen>
|
|
The <tt>entry</> command sets <em>entry_num</> as the current directory
|
|
entry.
|
|
|
|
<sect1>followinode
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: followinode
|
|
</verb></tscreen>
|
|
The <tt>followinode</> command will move you to the inode pointed by the
|
|
current directory entry.
|
|
|
|
<sect1>inode
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: inode
|
|
</verb></tscreen>
|
|
The <tt>inode</> command will return you to the parent inode of the whole
|
|
directory listing.
|
|
|
|
<sect1>next
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: next [num]
|
|
</verb></tscreen>
|
|
The <tt>next</> command will pass to the next directory entry.
|
|
If <em>num</> is supplied, it will pass to the next <em>num</> entries.
|
|
|
|
<sect1>prev
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: prev [num]
|
|
</verb></tscreen>
|
|
The <tt>prev</> command will pass to the previous directory entry.
|
|
If <em>num</> is supplied, it will pass to the previous <em>num</> entries.
|
|
|
|
<sect1>writedata
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: writedata
|
|
</verb></tscreen>
|
|
The <tt>writedata</> command will write the current directory entry to the
|
|
disk.
|
|
|
|
<sect><label id="block_bitmap">The block allocation bitmap
|
|
<p>
|
|
The <tt>block allocation bitmap</> of any block group can be reached from
|
|
the corresponding group descriptor.
|
|
|
|
You will be offered a bit listing of the entire blocks in the group. The
|
|
current block will be highlighted and its number will be displayed in the
|
|
status window.
|
|
|
|
A value of "1" means that the block is allocated, while a value of "0"
|
|
signals that it is free. The value is also interpreted in the status
|
|
window. You can use the usual <tt>next/prev</> commands, along with the
|
|
<tt>allocate/deallocate</> commands.
|
|
|
|
<sect1>allocate
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: allocate [num]
|
|
</verb></tscreen>
|
|
The <tt>allocate</> command allocates <em>num</> blocks, starting from the
|
|
highlighted position. If <em>num</> is not specified, <em>num=1</> is assumed.
|
|
Of-course, no actual change is made until you issue a <tt>writedata</> command.
|
|
|
|
<sect1>deallocate
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: deallocate [num]
|
|
</verb></tscreen>
|
|
The <tt>deallocate</> command deallocates <em>num</> blocks, starting from the
|
|
highlighted position. If <em>num</> is not specified, <em>num=1</> is assumed.
|
|
Of-course, no actual change is made until you issue a <tt>writedata</> command.
|
|
<tt>writedata</> command.
|
|
|
|
<sect1>entry
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: entry [entry_num]
|
|
</verb></tscreen>
|
|
The <tt>entry</> command sets the current highlighted block to
|
|
<em>entry_num</>.
|
|
|
|
<sect1>next
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: next [num]
|
|
</verb></tscreen>
|
|
The <tt>next</> command will pass to the next bit, which corresponds to the
|
|
next block. If <em>num</> is supplied, it will pass to the next <em>num</>
|
|
bits.
|
|
|
|
<sect1>prev
|
|
<p>
|
|
<tscreen><verb>
|
|
Syntax: prev [num]
|
|
</verb></tscreen>
|
|
The <tt>prev</> command will pass to the previous bit, which corresponds to the
|
|
previous block. If <em>num</> is supplied, it will pass to the previous
|
|
<em>num</> bits.
|
|
|
|
<sect>The inode allocation bitmap
|
|
<p>
|
|
|
|
The <tt>inode allocation bitmap</> is very similar to the block allocation
|
|
bitmap explained above. It is also reached from the corresponding group
|
|
descriptor. Please refer to section <ref id="block_bitmap">.
|
|
|
|
<sect>Filesystem size limitation
|
|
<p>
|
|
|
|
While an ext2 filesystem has a size limit of <tt>4 TB</>, EXT2ED currently
|
|
<tt>can't</> handle filesystems which are <tt>bigger than 2 GB</>.
|
|
|
|
I am sorry for the inconvenience. This will hopefully be fixed in future
|
|
releases.
|
|
|
|
<sect>Copyright
|
|
<p>
|
|
|
|
EXT2ED is Copyright (C) 1995 Gadi Oxman.
|
|
|
|
EXT2ED is hereby placed under the GPL - Gnu Public License. You are free and
|
|
welcome to copy, view and modify the sources. My only wish is that my
|
|
copyright presented above will be left and that a list of the bug fixes,
|
|
added features, etc, will be provided.
|
|
|
|
The entire EXT2ED project is based, of-course, on the kernel sources. The
|
|
<tt>ext2.descriptors</> distributed with EXT2ED is a slightly modified
|
|
version of the main ext2 include file, /usr/include/linux/ext2_fs.h. Follows
|
|
the original copyright:
|
|
|
|
<tscreen><verb>
|
|
/*
|
|
* linux/include/linux/ext2_fs.h
|
|
*
|
|
* Copyright (C) 1992, 1993, 1994, 1995
|
|
* Remy Card (card@masi.ibp.fr)
|
|
* Laboratoire MASI - Institut Blaise Pascal
|
|
* Universite Pierre et Marie Curie (Paris VI)
|
|
*
|
|
* from
|
|
*
|
|
* linux/include/linux/minix_fs.h
|
|
*
|
|
* Copyright (C) 1991, 1992 Linus Torvalds
|
|
*/
|
|
|
|
</verb></tscreen>
|
|
|
|
<sect>Acknowledgments
|
|
<p>
|
|
|
|
EXT2ED was constructed as a student project in the software
|
|
laboratory of the faculty of electrical-engineering in the
|
|
<tt>Technion - Israel's institute of technology</>.
|
|
|
|
At first, I would like to thank <tt>Avner Lottem</> and <tt>Doctor Ilana
|
|
David</> for their interest and assistance in this project.
|
|
|
|
I would also like to thank the following people, who were involved in the
|
|
design and implementation of the ext2 filesystem kernel code and support
|
|
utilities:
|
|
<itemize>
|
|
<item> <tt>Remy Card</>
|
|
|
|
Who designed, implemented and maintains the ext2 filesystem kernel
|
|
code, and some of the ext2 utilities. Remy Card is also the author
|
|
of several helpful slides concerning the ext2 filesystem.
|
|
Specifically, he is the author of <tt>File Management in the Linux
|
|
Kernel</> and of <tt>The Second Extended File System - Current State,
|
|
Future Development</>.
|
|
|
|
<item> <tt>Wayne Davison</>
|
|
|
|
Who designed the ext2 filesystem.
|
|
<item> <tt>Stephen Tweedie</>
|
|
|
|
Who helped designing the ext2 filesystem kernel code and wrote the
|
|
slides <tt>Optimizations in File Systems</>.
|
|
<item> <tt>Theodore Ts'o</>
|
|
|
|
Who is the author of several ext2 utilities and of the ext2 library
|
|
<tt>libext2fs</> (which I didn't use, simply because I didn't know
|
|
it exists when I started to work on my project).
|
|
</itemize>
|
|
|
|
Lastly, I would like to thank, of-course, <tt>Linus Torvalds</> and the
|
|
<tt>Linux community</> for providing all of us with such a great operating
|
|
system.
|
|
|
|
Please contact me in a case of bug report, suggestions, or just about
|
|
anything concerning EXT2ED.
|
|
|
|
Enjoy,
|
|
|
|
Gadi Oxman <tgud@tochnapc2.technion.ac.il>
|
|
|
|
Haifa, August 95
|
|
</article> |