On Wed, May 28, 2008 at 7:03 PM, Prasad Joshi <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, May 28, 2008 at 6:45 PM, Manish Katiyar <[EMAIL PROTECTED]> wrote:
>>
>> On Wed, May 28, 2008 at 5:55 PM, Prasad Joshi <[EMAIL PROTECTED]>
>> wrote:
>> > Yes, I read the code
>> >
>> > On Wed, May 28, 2008 at 5:44 PM, Manish Katiyar <[EMAIL PROTECTED]>
>> > wrote:
>> >>
>> >> On Wed, May 28, 2008 at 5:43 PM, Manish Katiyar <[EMAIL PROTECTED]>
>> >> wrote:
>> >> > On Wed, May 28, 2008 at 5:06 PM, Prasad Joshi
>> >> > <[EMAIL PROTECTED]>
>> >> > wrote:
>> >> >> Thanks a lot for all the replies.
>> >> >>
>> >> >> I am able to use the debugfs. But, I am not able to understand the
>> >> >> information displayed by ls -l command in the debugfs env
>> >> >> Here, is a sample output
>> >> >>
>> >> >> This is the current directory structure (file system is mounted at
>> >> >> /mnt)
>> >> >> /mnt/
>> >> >> |--------------- dir
>> >> >> | |----------------- 1
>> >> >> |--------------- lost+found
>> >> >> |--------------- test
>> >> >> |--------------- test1
>> >> >> |--------------- test2
>> >> >>
>> >> >> test1 and test2 are hard links to file test (there is no data in the
>> >> >> file)
>> >> >>
>> >> >> HERE IS THE OUTPUT
>> >> >>
>> >> >> debugfs: ls -l
>> >> >> 2 40755 (2) 0 0 1024 27-May-2008 20:03 .
>> >> >> 2 40755 (2) 0 0 1024 27-May-2008 20:03 ..
>> >> >> 11 40700 (2) 0 0 12288 27-May-2008 20:02
>> >> >> lost+found
>> >> >> 12 100644 (1) 0 0 1037 27-May-2008 20:05 test
>> >> >> 13 40755 (2) 0 0 2048 27-May-2008 20:08 dir
>> >> >> 12 100644 (1) 0 0 1037 27-May-2008 20:05 test1
>> >> >> 12 100644 (1) 0 0 1037 27-May-2008 20:05 test2
>> >> >>
>> >> >> debugfs: ls -l dir
>> >> >> 13 40755 (2) 0 0 2048 27-May-2008 20:08 .
>> >> >> 2 40755 (2) 0 0 1024 27-May-2008 20:03 ..
>> >> >> 14 40755 (2) 0 0 1024 28-May-2008 15:48 1
>> >> >> 0 0 (0) 0 0 0
>> >> >>
>> >> >> debugfs: ls -l dir/1
>> >> >> 14 40755 (2) 0 0 1024 28-May-2008 15:48 .
>> >> >> 13 40755 (2) 0 0 2048 27-May-2008 20:08 ..
>> >> >>
>> >> >> debugfs: mkdir dir/2
>> >> >> debugfs: ls -l
>> >> >> 2 40755 (2) 0 0 1024 27-May-2008 20:03 .
>> >> >> 2 40755 (2) 0 0 1024 27-May-2008 20:03 ..
>> >> >> 11 40700 (2) 0 0 12288 27-May-2008 20:02
>> >> >> lost+found
>> >> >> 12 100644 (1) 0 0 1037 27-May-2008 20:05 test
>> >> >> 13 40755 (2) 0 0 2048 27-May-2008 20:08 dir
>> >> >> 12 100644 (1) 0 0 1037 27-May-2008 20:05 test1
>> >> >> 12 100644 (1) 0 0 1037 27-May-2008 20:05 test2
>> >> >>
>> >> >> debugfs: ls -l dir
>> >> >> 13 40755 (2) 0 0 2048 27-May-2008 20:08 .
>> >> >> 2 40755 (2) 0 0 1024 27-May-2008 20:03 ..
>> >> >> 14 40755 (2) 0 0 1024 28-May-2008 15:48 1
>> >> >> 15 40755 (2) 0 0 1024 28-May-2008 16:51 2
>> >> >> 0 0 (0) 0 0 0
>> >> >>
>> >> >> Can any one please tell me what these collumns represent?
>> >> >
>> >> > It appears you are using debugfs from e2fsprogs. The columns seem to
>> >> > be
>> >> >
>> >> > 1) inode number
>> >> > 2) permissons/mode,
>> >> > 3) From the code it is "dirent->name_len >> 8", but my guess is it is
>> >> > number of links.
>> >> > 4) uid
>> >> > 5) gid
>> >> 6) There is size too :-)
>> >> > 6) datetime string
>> >> > 7) file name.
>> >> >
>> >> >
>> >> > Hope that helps.
>> >
>> > Yes correct, I also went through the code of e2fsprogs. File for ls code
>> > is
>> > debugfs/ls.c
>> > 1. Inode Number
>> > 2. Inode Mode.
>> > 3. dirent->name_len >> 8 it is lenght in bytes
>>
>> How does this come to 2 then ?
>>
>> 11 40700 (2) 0 0 12288 27-May-2008 20:02 lost+found
>>
>> Since it is a directory, the link count should be minimum 2.
>
> This is the code which is doing the printing
>
> fprintf(ls->f, "%c%6u%c %6o (%d) %5d %5d ", lbr, ino,
> rbr,
> inode.i_mode, dirent->name_len >> 8,
> inode_uid(inode), inode_gid(inode));
>
> It is not link count. If you see test file has 3 links test, test1, and
> test3. So, the number in the Bracket is not the link count
Hmmm... it is indeed dirent->name_len as shown by gdb below
Breakpoint 1, list_dir_proc (dir=2, entry=2, dirent=0x80862f4,
offset=12, blocksize=1024, buf=0x80862e8 "\002",
private=0xbfd6faf4) at ls.c:51
51 {
(gdb) p *dirent
$1 = {inode = 2, rec_len = 12, name_len = 514,
name =
"..\000\000\v\000\000\000\024\000\n\002lost+found\000\000\f\000\000\000\f\000\004\001test\r\000\000\000\020\000\005\atest1\000\000\000\016\000\000\000\020\000\005\atest2\000\000\000\017\000\000\000�\003\005\atest3",
'\0' <repeats 173 times>}
(gdb) ptype dirent
type = struct ext2_dir_entry {
__u32 inode;
__u16 rec_len;
__u16 name_len;
char name[255];
} *
(gdb) p 514>>8
$2 = 2
But why the name_len for ".." is 514 is what I need to find out
because this should hold the actual name of the directory entry if I
understand correctly and even the below link says so :-(
http://www.linux-security.cn/ebooks/ulk3-html/0596005652/understandlk-CHP-18-SECT-2.html
>
> debugfs: stat test
> Inode: 12 Type: regular Mode: 0644 Flags: 0x0 Generation:
> 3442830008
> User: 0 Group: 0 Size: 1037
> File ACL: 338 Directory ACL: 0
> Links: 3 Blockcount: 6
> Fragment: Address: 0 Number: 0 Size: 0
> ctime: 0x483d4909 -- Wed May 28 17:29:05 2008
> atime: 0x483d496e -- Wed May 28 17:30:46 2008
> mtime: 0x483c1c18 -- Tue May 27 20:05:04 2008
> BLOCKS:
> (0-1):7169-7170
> TOTAL: 2
>
> debugfs: ls -l
> 2 40755 (2) 0 0 1024 27-May-2008 20:03 .
> 2 40755 (2) 0 0 1024 27-May-2008 20:03 ..
> 11 40700 (2) 0 0 12288 27-May-2008 20:02 lost+found
> 12 100644 (1) 0 0 1037 27-May-2008 20:05 test
> 13 40755 (2) 0 0 2048 27-May-2008 20:08 dir
> 12 100644 (1) 0 0 1037 27-May-2008 20:05 test1
> 12 100644 (1) 0 0 1037 27-May-2008 20:05 test2
>
>>
>>
>>
>> > 4. UID
>> > 5. GID
>> > 6. Date
>> > 7. File Name
>> >
>> > Thanks a lot for your reply.
>> > --Prasad.
>> >
>> >>
>> >> >
>> >> >
>> >> >>
>> >> >> Thanks and Regards,
>> >> >> Prasad.
>> >> >>
>> >> >> On Wed, May 28, 2008 at 8:00 AM, Peter Teoh
>> >> >> <[EMAIL PROTECTED]>
>> >> >> wrote:
>> >> >>>
>> >> >>> On Wed, May 28, 2008 at 12:17 AM, Frédéric Weisbecker
>> >> >>> <[EMAIL PROTECTED]> wrote:
>> >> >>> > Hi!
>> >> >>> >
>> >> >>> > Here is a small tutorial:
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > http://docs.blackfin.uclinux.org/doku.php?id=file_systems#file_system_exampledebugfs
>> >> >>>
>> >> >>> Yes, that is the kernel-based debugfs, and u used it via the
>> >> >>> following
>> >> >>> manner (not mentioned in the page, but widely available in
>> >> >>> Internet):
>> >> >>>
>> >> >>> Method 1:
>> >> >>>
>> >> >>> put the following line in /etc/fstab for automatic moutning at
>> >> >>> bootup:
>> >> >>>
>> >> >>> none /sys/kernel/debug debugfs
>> >> >>> defaults 0 0
>> >> >>>
>> >> >>>
>> >> >>> Method 2:
>> >> >>>
>> >> >>> Issue:
>> >> >>>
>> >> >>> mount -t debugfs none /sys/kernel/debug
>> >> >>>
>> >> >>> at command line level.
>> >> >>>
>> >> >>> BUT....in my Fedora FC7 distros, at the commandline level there is
>> >> >>> a
>> >> >>> "debugfs" command (man debugfs):
>> >> >>>
>> >> >>> DEBUGFS(8)
>> >> >>> DEBUGFS(8)
>> >> >>>
>> >> >>> NAME
>> >> >>> debugfs - ext2/ext3 file system debugger
>> >> >>>
>> >> >>> SYNOPSIS
>> >> >>> debugfs [ -Vwci ] [ -b blocksize ] [ -s superblock ] [ -f
>> >> >>> cmd_file
>> >> >>> ] [
>> >> >>> -R request ] [ -d data_source_device ] [ device ]
>> >> >>>
>> >> >>> DESCRIPTION
>> >> >>> The debugfs program is an interactive file system debugger.
>> >> >>> It
>> >> >>> can
>> >> >>> be
>> >> >>> used to examine and change the state of an ext2 file system.
>> >> >>> device is the special file corresponding to the device
>> >> >>> containing
>> >> >>> the
>> >> >>> ext2 file system (e.g /dev/hdXX).
>> >> >>>
>> >> >>> OPTIONS
>> >> >>> -w Specifies that the file system should be opened in
>> >> >>> read-write
>> >> >>> mode. Without this option, the file system is
>> >> >>> opened
>> >> >>> in
>> >> >>> read-
>> >> >>> only mode.
>> >> >>>
>> >> >>> .........
>> >> >>>
>> >> >>> Very confusing.....but I think this is not what u want....it is a
>> >> >>> tool
>> >> >>> as part of the e2fsprogs package (e2fsprogs.sourceforge.net, I
>> >> >>> think).
>> >> >>>
>> >> >>>
>> >> >>> > If you need more help to use it, don't hesitate to ask!
>> >> >>> > As you will see there are two ways to use it:
>> >> >>> >
>> >> >>> > _ By creating a file which exports or import a single variable.
>> >> >>> > It's
>> >> >>> > simple
>> >> >>> > but asynchronous (you or the user-process needs to check
>> >> >>> > periodically if
>> >> >>> > the
>> >> >>> > value has changed.
>> >> >>> > _ By implementing the common file operations. But it stays simple
>> >> >>> > and
>> >> >>> > it's
>> >> >>> > synchronous.
>> >> >>> >
>> >> >>> > Regards,
>> >> >>> > Frédéric...
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > 2008/5/27 Prasad Joshi <[EMAIL PROTECTED]>:
>> >> >>> >>
>> >> >>> >> Hi All,
>> >> >>> >>
>> >> >>> >> I have an assignment and I am supposed to use debugfs for the
>> >> >>> >> same.
>> >> >>> >> Can anyone please help me? or Point me to a link which tells
>> >> >>> >> how
>> >> >>> >> to
>> >> >>> >> use
>> >> >>> >> debug fs?
>> >> >>> >>
>> >> >>> >> Thanks and Regards,
>> >> >>> >> Prasad
>> >> >>> >
>> >> >>> >
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Regards,
>> >> >>> Peter Teoh
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Thanks & Regards,
>> >> > ********************************************
>> >> > Manish Katiyar ( http://mkatiyar.googlepages.com )
>> >> > 3rd Floor, Fair Winds Block
>> >> > EGL Software Park
>> >> > Off Intermediate Ring Road
>> >> > Bangalore 560071, India
>> >> > ***********************************************
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Thanks & Regards,
>> >> ********************************************
>> >> Manish Katiyar ( http://mkatiyar.googlepages.com )
>> >> 3rd Floor, Fair Winds Block
>> >> EGL Software Park
>> >> Off Intermediate Ring Road
>> >> Bangalore 560071, India
>> >> ***********************************************
>> >
>> >
>>
>>
>>
>> --
>> Thanks & Regards,
>> ********************************************
>> Manish Katiyar ( http://mkatiyar.googlepages.com )
>> 3rd Floor, Fair Winds Block
>> EGL Software Park
>> Off Intermediate Ring Road
>> Bangalore 560071, India
>> ***********************************************
>
>
--
Thanks & Regards,
********************************************
Manish Katiyar ( http://mkatiyar.googlepages.com )
3rd Floor, Fair Winds Block
EGL Software Park
Off Intermediate Ring Road
Bangalore 560071, India
***********************************************
