Post by Bill Cunni » Fri, 17 Apr 2009 10:47:22

Can I use any functions that could tell me the number of inodes on my
filesystem and their addresses?



Post by » Fri, 17 Apr 2009 13:13:31

> Can I use any functions that could tell me the number of inodes on my

"df -i" can tell you the number of free inodes on a disk partition.

BSD systems have statfs() and fstatfs() which will return a bunch of
info about a disk filesystem such as free disk space and inodes,
block size, I/O statistics.

What's the "address" of an inode? If a filesystem has N inodes, they
are generally numbered from 1 to N inclusive, although 1 may be reserved
for something strange (like attaching bad disk blocks to it).



Post by Bill Cunni » Sat, 18 Apr 2009 09:10:00

I guess what I mean about "the address" of an inode is where it is in
the filesystem. Maybe I'm showing my ignorance about filesystems but that
leads me to another question. Files that have been deleted can they be
recovered by finding superblock info? How would I go about looking at the
superblock. The FS I'm using now is ext3.



Post by gordonb.qp » Sat, 18 Apr 2009 18:13:57

>> "df -i" can tell you the number of free inodes on a disk partition.

You want very, very accurate GPS coordinates of a possibly large
collection of disk blocks? Remember, those change constantly while
the disk is spinning.

If you want the offset from the beginning of the disk partition
where the inode is stored, that depends on the filesystem. Old-style
UNIX filesystems (e.g. UNIX v7) had the inodes in one big block and
the byte offset for inode N was some fixed offset (to skip over the
super block) + 64 bytes * inode number. Newer types of filesystems
spread the inodes out over the disk. Also, inodes are bigger.
If you know the format of the filesystem, finding an inode by number
shouldn't be very difficult, as it's done every time you open a file.

The super block is likely a fixed offset from the beginning of the
disk (maybe block 1, with counting starting at 0) and may be
replicated multiple times in the file system (although the free
list may not be kept up to date in the copies). For example, on
BSD ffs filesystems, a duplicate super block is at block 32 for
ufs1 and block 160 for ufs2.

The disk block numbers of a deleted file *USED TO BE* stored in the
inode or indirect blocks hung off the inode. They are erased when
the file is deleted (or, in the case of BSD soft-updates, shortly
afterwards). Keeping consistency between claimed blocks and the
free block list is a major part of what fsck does when dealing with
an active filesystem with an unclean shutdown.

The "free list", which might or might not actually be a list, will
contain block numbers of recently (as well as not-so-recently)
deleted files, possibly in some kind of order. The beginning or
the end of the free list might reflect the blocks in the latest
deleted file(s) in forward or reverse order. In some filesystems,
the so-called "free list" is a bit map. In this type of filesystem,
the best you can hope for is a list of blocks that *might* have
been part of the file, in an order unrelated to the order of the
blocks in the file.

Note that unless you managed to accidentally delete a file, followed
by *ABSOLUTELY NO CHANGES* to that partition, information you need
to recover a file may be overwritten. Probably the worst-case
scenario is an indirect block being overwritten. Next is file data
being overwritten.


Post by Bill Cunni » Sun, 19 Apr 2009 02:48:34

I'm getting into the realm of computer forensics here. Do you happen to
know where there's specs on ext3 and the unix ffs's ? I have a copy of an
old V7 that I run on a pdp11 simulator. Between it and minix I might learn
something. But key words like "register" are used on that old pre-ansi C
system. Then again it my be best to learn with modern systems like ext3-4.



Post by gordonb.kk » Sun, 19 Apr 2009 10:27:01

> I'm getting into the realm of computer forensics here. Do you happen to

I don't know of a good writeup that addresses stuff you're looking
for. Google might come up with a number of papers addressing performance
which might get into the structure and how it affects performance.

FreeBSD and Linux both come with source code, which might be necessary to
deal with stuff that isn't guaranteed by the file system (like what order
freed blocks are listed in a superblock, if any).

"register" variables are perfectly good ANSI C.

That depends on what you're trying to do. If you are trying to sell
the FBI a tool to recover Minix files, you're going to have an uphill
battle convincing them that even one bad guy runs Minix. Linux or
FreeBSD are used by lots of people.


Post by Bill Cunni » Mon, 20 Apr 2009 03:43:46

What you you recommend for having source code available the most?
freeBSD or netBSD? I want kernel source code too. Source for all the
commands and I can always use GNU source with it I suppose. I have run
netBSD with a VAX emulator. There wasn't enough source code there for me.



Post by dfighte » Mon, 20 Apr 2009 04:57:25

I have no idea about netBSD, but I know that freeBSD has an all-in-one
public ro CVS repo., that you can browse even through your web browser.


Post by markhoble » Mon, 20 Apr 2009 05:08:02

I've just looked at this, because I want to be able to roll out distributions
from a source tree, so it is imperative that systems that I use are fully open
source. The documentation is not always clear. Documents talk of freebsd
being open source, but some documents say that the kernel contains binary
blobs. The netbsd project says on its front page that it is open source, but
other documentation states that the netbsd kernel contains binary blobs.

binary blobs <> open source

The openbsd project has a policy not to accept binary blobs in the kernel, so I
guess that is the one to choose at this time. Unfortunately, I couldn't get
openbsd to work here because of problems with my network cards. I'm trying to
build another machine with a different network card to retest this.


Mark Hobley
Linux User: #370818


Post by gordonb.6m » Tue, 21 Apr 2009 08:37:16

>> That depends on what you're trying to do. If you are trying to sell

As far as I know, even Linux advocates have not progressed to the point
of attaching Linux source CDROMs to rocks and throwing them through
windows unsolicited, so you'll need to download it.

I thought the binary blob issue was mostly for drivers of things like
video cards. I'll admit I haven't checked the source tree for binary
blobs, although I do regularly upgrade FreeBSD by building the source
and installing it.

You might get more source code if you stop using emulators for obsolete
machines like VAX and PDP-11 and use more modern hardware.