[PATCH 1/2] Implement support for checking /proc/PID/coredump_filter
Pedro Alves
palves@redhat.com
Mon Mar 23 20:36:00 GMT 2015
On 03/23/2015 06:40 PM, Sergio Durigan Junior wrote:
> Done. Patch attached. I will wait until you look at the second patch
> (and approve it) in order to commit everything together.
Thanks. FAOD, this version is OK.
On 03/23/2015 06:40 PM, Sergio Durigan Junior wrote:
> Jan has provided a good example of it before. When you use stat -L, you
> can see if the 'Links' count is zero (which means the real file has been
> really deleted). For example:
>
> lrw-------. 1 sergio sergio 64 Mar 23 14:34 7f2c5911b000-7f2c5911c000 -> /tmp/t2 (deleted)
> [root@bla map_files]# stat -L 7f2c5911b000-7f2c5911c000
> File: â7f2c5911b000-7f2c5911c000â
> Size: 0 Blocks: 0 IO Block: 4096 regular empty file
> Device: 23h/35d Inode: 217633770 Links: 1
>
> The 'Links' is 1 because, despite the fact that 't2' has been deleted,
> the original file 't1' still exists. However, if I remove 't1':
>
> [root@bla map_files]# stat -L 7f2c5911b000-7f2c5911c000
> File: â7f2c5911b000-7f2c5911c000â
> Size: 0 Blocks: 0 IO Block: 4096 regular empty file
> Device: 23h/35d Inode: 217633770 Links: 0
>
> Therefore, it should be possible to use stat even in this case. But
> anyway, this was just FYI, we're not doing that.
Ah, yes, these files really work as symlinks, so ls -l was just
showing the symlink's own link count. "ls -l -L" works too.
Thanks,
Pedro Alves
More information about the Gdb-patches
mailing list