Re: st_size of a symlink

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

 



On Mon, 23 Jul 2012, Richard Weinberger wrote:

> Hi!
> 
> lstat(2) on /proc/$pid/exe gives me a stat object where st_size is 0.
> 
> Or:
> rw@mantary:~> ls -l /proc/$$/exe
> lrwxrwxrwx 1 rw users 0 23. Jul 17:02 /proc/16902/exe -> /bin/bash
> 
> The lstat(2) manpage says:
> "The st_size field gives the size of the file (if it is a regular file or a
> symbolic link) in bytes.  The size of a symbolic link is the length of the
> pathname it contains, without a terminating null byte."
> 
> This property is also used in the example in the readlink(2) manpage.
> 
> Is this a procfs issue or is the manpage wrong?
> 
I have relied on that behaviour (size of symlink being lengh of pathname 
it contains) in the past, so I know it used to work and I'd expect it to 
keep working.
I honestly never really thought about procfs, but checking now, it does 
seem that procfs doesn't quite do things right...

Just so we all know what kernel I'm running:
  [root@arch tmp]# uname -a
  Linux arch 3.4.6-1-ARCH #1 SMP PREEMPT Fri Jul 20 08:21:26 CEST 2012 x86_64 GNU/Linux

Let's see what procfs reports:
  [root@arch ~]# ls -l /proc/$$/exe
  lrwxrwxrwx 1 root root 0 Jul 23 19:58 /proc/884/exe -> /bin/bash
Doesn't seem quite right....

Now let's see what tmpfs reports:
  [root@arch tmp]# mount | grep /tmp
  tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
  [root@arch ~]# cd /tmp
  [root@arch tmp]# ln -s /tmp foo
  [root@arch tmp]# ls -l foo
  lrwxrwxrwx 1 root root 4 Jul 23 19:59 foo -> /tmp
Seems OK.

Let's check ext4:
  [root@arch tmp]# mount | grep /home
  /dev/sda4 on /home type ext4 (rw,relatime,data=ordered)
  [root@arch tmp]# cd /home/jj
  [root@arch jj]# touch foo
  [root@arch jj]# ln -s foo bar
  [root@arch jj]# ls -l bar
  lrwxrwxrwx 1 root root 3 Jul 23 20:03 bar -> foo
Seems OK as well..

So how about devtmpfs?
  [root@arch jj]# mount | grep devtmpfs
  dev on /dev type devtmpfs (rw,nosuid,relatime,size=779400k,nr_inodes=194850,mode=755)
  [root@arch jj]# ls -l /dev/stderr 
  lrwxrwxrwx 1 root root 15 Jul 23 19:46 /dev/stderr -> /proc/self/fd/2
Also looks OK...

So, from my point of view it looks like procfs is the one who has got it 
wrong.
We should probably fix that (IMVHO).


-- 
Jesper Juhl <jj@xxxxxxxxxxxxx>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux