Re: [PATCH 1/2] Implement support for checking /proc/PID/coredump_filter

[Pedro Alves <palves@redhat.com>]

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