* st_size of a symlink
@ 2012-07-23 15:55 ` Richard Weinberger
0 siblings, 0 replies; 12+ messages in thread
From: Richard Weinberger @ 2012-07-23 15:55 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-fsdevel, linux-man
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?
Thanks,
//richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* st_size of a symlink
@ 2012-07-23 15:55 ` Richard Weinberger
0 siblings, 0 replies; 12+ messages in thread
From: Richard Weinberger @ 2012-07-23 15:55 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, linux-man-u79uwXL29TY76Z2rM5mHXA
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?
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
@ 2012-07-23 18:09 ` Jesper Juhl
0 siblings, 0 replies; 12+ messages in thread
From: Jesper Juhl @ 2012-07-23 18:09 UTC (permalink / raw)
To: Richard Weinberger; +Cc: linux-kernel, linux-fsdevel, linux-man
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@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
@ 2012-07-23 18:09 ` Jesper Juhl
0 siblings, 0 replies; 12+ messages in thread
From: Jesper Juhl @ 2012-07-23 18:09 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA
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-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org> 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-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
2012-07-23 18:09 ` Jesper Juhl
(?)
@ 2012-07-23 20:22 ` Al Viro
2012-07-23 20:47 ` Jesper Juhl
-1 siblings, 1 reply; 12+ messages in thread
From: Al Viro @ 2012-07-23 20:22 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Richard Weinberger, linux-kernel, linux-fsdevel, linux-man
On Mon, Jul 23, 2012 at 08:09:14PM +0200, Jesper Juhl wrote:
> So, from my point of view it looks like procfs is the one who has got it
> wrong.
> We should probably fix that (IMVHO).
Fix it _how_? Try to rename a binary you have running in a process.
Or rename its cwd. Or rename an opened file. Watch the corresponding
procfs symlink (still pointing to the swame object) change. With
no way to tell that some sucker had looked at st_size some time ago
and might get surprised by the change.
The fact is, st_size is just a useful hint for symlink target length.
It tells you the likely sufficient size of buffer. There's a reason
why readlink(2) returns what it returns; you *can't* rely on the
earlier lstat() results or, for that matter, any prior information.
If nothing else, I could rm that symlink and create a new one in
the meanwhile. You need to check what it had returned and deal with
insufficient buffer size. By retrying readlink() with bigger buffer.
With procfs there's just a few more ways the readlink() output can
change, that's all.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
@ 2012-07-23 20:47 ` Jesper Juhl
0 siblings, 0 replies; 12+ messages in thread
From: Jesper Juhl @ 2012-07-23 20:47 UTC (permalink / raw)
To: Al Viro; +Cc: Richard Weinberger, linux-kernel, linux-fsdevel, linux-man
On Mon, 23 Jul 2012, Al Viro wrote:
> On Mon, Jul 23, 2012 at 08:09:14PM +0200, Jesper Juhl wrote:
> > So, from my point of view it looks like procfs is the one who has got it
> > wrong.
> > We should probably fix that (IMVHO).
>
> Fix it _how_?
By returning the size as the number of bytes in the name the link is
currently pointing at.
> Try to rename a binary you have running in a process.
> Or rename its cwd. Or rename an opened file. Watch the corresponding
> procfs symlink (still pointing to the swame object) change. With
> no way to tell that some sucker had looked at st_size some time ago
> and might get surprised by the change.
>
Sure, length's may change and an app needs to be prepared for that, but
that's no reason to always return 0 (zero) for length for links in procfs.
We can do better and return the actual length of whatever the link is
pointing to currently - just like other filesystems do.
> The fact is, st_size is just a useful hint for symlink target length.
Sure.
> It tells you the likely sufficient size of buffer. There's a reason
> why readlink(2) returns what it returns; you *can't* rely on the
> earlier lstat() results or, for that matter, any prior information.
I know that. That's not the issue. The issue is that procfs *could* return
more useful info than it does currently.
> If nothing else, I could rm that symlink and create a new one in
> the meanwhile. You need to check what it had returned and deal with
> insufficient buffer size.
Of course.
> By retrying readlink() with bigger buffer.
> With procfs there's just a few more ways the readlink() output can
> change, that's all.
>
Still not a good reason to just return 0 IMHO.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
@ 2012-07-23 20:47 ` Jesper Juhl
0 siblings, 0 replies; 12+ messages in thread
From: Jesper Juhl @ 2012-07-23 20:47 UTC (permalink / raw)
To: Al Viro
Cc: Richard Weinberger, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA
On Mon, 23 Jul 2012, Al Viro wrote:
> On Mon, Jul 23, 2012 at 08:09:14PM +0200, Jesper Juhl wrote:
> > So, from my point of view it looks like procfs is the one who has got it
> > wrong.
> > We should probably fix that (IMVHO).
>
> Fix it _how_?
By returning the size as the number of bytes in the name the link is
currently pointing at.
> Try to rename a binary you have running in a process.
> Or rename its cwd. Or rename an opened file. Watch the corresponding
> procfs symlink (still pointing to the swame object) change. With
> no way to tell that some sucker had looked at st_size some time ago
> and might get surprised by the change.
>
Sure, length's may change and an app needs to be prepared for that, but
that's no reason to always return 0 (zero) for length for links in procfs.
We can do better and return the actual length of whatever the link is
pointing to currently - just like other filesystems do.
> The fact is, st_size is just a useful hint for symlink target length.
Sure.
> It tells you the likely sufficient size of buffer. There's a reason
> why readlink(2) returns what it returns; you *can't* rely on the
> earlier lstat() results or, for that matter, any prior information.
I know that. That's not the issue. The issue is that procfs *could* return
more useful info than it does currently.
> If nothing else, I could rm that symlink and create a new one in
> the meanwhile. You need to check what it had returned and deal with
> insufficient buffer size.
Of course.
> By retrying readlink() with bigger buffer.
> With procfs there's just a few more ways the readlink() output can
> change, that's all.
>
Still not a good reason to just return 0 IMHO.
--
Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org> 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-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
2012-07-23 18:09 ` Jesper Juhl
(?)
(?)
@ 2012-07-23 21:53 ` Sam Varshavchik
-1 siblings, 0 replies; 12+ messages in thread
From: Sam Varshavchik @ 2012-07-23 21:53 UTC (permalink / raw)
To: Jesper Juhl, linux-man-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
Jesper Juhl writes:
> 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....
That's because it looks like a symlink, it feels like a symlink, but it's
not really a symlink.
> So, from my point of view it looks like procfs is the one who has got it
> wrong.
> We should probably fix that (IMVHO).
If you remove a running process's executable, that "symlink" will now read
"$filename (deleted)".
Surprisingly, you will be able to open(2) this alleged "symlink".
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
2012-07-23 20:47 ` Jesper Juhl
(?)
@ 2012-07-23 22:07 ` Richard Weinberger
2012-07-23 23:13 ` Guillem Jover
-1 siblings, 1 reply; 12+ messages in thread
From: Richard Weinberger @ 2012-07-23 22:07 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Al Viro, linux-kernel, linux-fsdevel, linux-man
On 23.07.2012 22:47, Jesper Juhl wrote:
>> Fix it _how_?
>
> By returning the size as the number of bytes in the name the link is
> currently pointing at.
This is not easy.
procfs has no clue where the link pointing at.
The information is generated while accessing the link.
tmpfs on the other hand has this information because symlinks get only
changed through tmpfs...
>> By retrying readlink() with bigger buffer.
>> With procfs there's just a few more ways the readlink() output can
>> change, that's all.
>>
> Still not a good reason to just return 0 IMHO.
IMHO the lstat() and readlink() manpages have to be more precise about
st_size.
Thanks,
//richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
2012-07-23 22:07 ` Richard Weinberger
@ 2012-07-23 23:13 ` Guillem Jover
2012-07-24 10:16 ` Richard Weinberger
0 siblings, 1 reply; 12+ messages in thread
From: Guillem Jover @ 2012-07-23 23:13 UTC (permalink / raw)
To: Richard Weinberger
Cc: Jesper Juhl, Al Viro, linux-kernel, linux-fsdevel, linux-man
On Tue, 2012-07-24 at 00:07:48 +0200, Richard Weinberger wrote:
> On 23.07.2012 22:47, Jesper Juhl wrote:
> >>Fix it _how_?
> >
> >By returning the size as the number of bytes in the name the link is
> >currently pointing at.
>
> This is not easy.
> procfs has no clue where the link pointing at.
> The information is generated while accessing the link.
> tmpfs on the other hand has this information because symlinks get
> only changed through tmpfs...
Well, can't the link be accessed when getting the stat information
then?
> >> By retrying readlink() with bigger buffer.
> >>With procfs there's just a few more ways the readlink() output can
> >>change, that's all.
> >>
> >Still not a good reason to just return 0 IMHO.
>
> IMHO the lstat() and readlink() manpages have to be more precise
> about st_size.
They document what POSIX says:
<http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html>
regards,
guillem
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
@ 2012-07-24 10:16 ` Richard Weinberger
0 siblings, 0 replies; 12+ messages in thread
From: Richard Weinberger @ 2012-07-24 10:16 UTC (permalink / raw)
To: Guillem Jover
Cc: Jesper Juhl, Al Viro, linux-kernel, linux-fsdevel, linux-man
On 24.07.2012 01:13, Guillem Jover wrote:
> Well, can't the link be accessed when getting the stat information
> then?
Sure, but it's not trivial.
>> IMHO the lstat() and readlink() manpages have to be more precise
>> about st_size.
>
> They document what POSIX says:
This does not make it any better...
Thanks,
//richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: st_size of a symlink
@ 2012-07-24 10:16 ` Richard Weinberger
0 siblings, 0 replies; 12+ messages in thread
From: Richard Weinberger @ 2012-07-24 10:16 UTC (permalink / raw)
To: Guillem Jover
Cc: Jesper Juhl, Al Viro, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA
On 24.07.2012 01:13, Guillem Jover wrote:
> Well, can't the link be accessed when getting the stat information
> then?
Sure, but it's not trivial.
>> IMHO the lstat() and readlink() manpages have to be more precise
>> about st_size.
>
> They document what POSIX says:
This does not make it any better...
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-07-24 10:17 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-23 15:55 st_size of a symlink Richard Weinberger
2012-07-23 15:55 ` Richard Weinberger
2012-07-23 18:09 ` Jesper Juhl
2012-07-23 18:09 ` Jesper Juhl
2012-07-23 20:22 ` Al Viro
2012-07-23 20:47 ` Jesper Juhl
2012-07-23 20:47 ` Jesper Juhl
2012-07-23 22:07 ` Richard Weinberger
2012-07-23 23:13 ` Guillem Jover
2012-07-24 10:16 ` Richard Weinberger
2012-07-24 10:16 ` Richard Weinberger
2012-07-23 21:53 ` Sam Varshavchik
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.