Re: [Xen-devel] [PATCH 1/2] tools/helpers: Introduce cmp-fd-file-inode utility

[Jason Andryuk <jandryuk@xxxxxxxxx>]

On Thu, Mar 5, 2020 at 2:12 PM Ian Jackson <ian.jackson@xxxxxxxxxx> wrote:
>
> Jason Andryuk writes ("Re: [PATCH 1/2] tools/helpers: Introduce 
> cmp-fd-file-inode utility"):
> > I'd be happy to use stat if it works.  The comment in locking.sh above
> > the usage is:
> >         # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or
> >         # use bash's test -ef because those all go through what is
> >         # actually a synthetic symlink in /proc and we aren't
> >         # guaranteed that our stat(2) won't lose the race with an
> >         # rm(1) between reading the synthetic link and traversing the
> >         # file system to find the inum.  Perl is very fast so use that.
> >
> > ...which I thought ruled out stat.
>
> Well read.
>
> I have done some more testing and in my tests (on Debian stretch)
>     stat -L - <some-file
> does this
>     fstat64(0, {st_mode=S_IFREG|0664, st_size=117844, ...}) = 0
> (according to strace) which is precisely what is needed.
>
> Oddly, it also does this
>     fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 171), ...}) = 0
> but it doesn't seem to do anything with the results, so I think
> that's harmless.

I think this stat is from glibc before printing.  `stat file -`
re-orders the fstat(1) before fstat(0).

> I wrote that comment in 2012.  Presumably `stat -L -' has appeared in
> the meantime.

I peaked at coreutils git, and - was added in 2009.  But I had no idea
of the magic '-'.  Thank you for finding it.

> The synthetic symlink may be a red herring anyway; nowadays at least,
> I am told by someone who read the Linux kernel source that
>   the name comes from the `readlink' method on the link inode, but a
>   different method entirely -- `get_link' -- is used by `namei' to
>   actually resolve the link to a destination inode.
>
> But using `-' is clearly fine, like this I think:
>
> mariner:~> stat -c%D.%i -L - t <t
> fe04.844307
> fe04.844307
> mariner:~>
>
> Sorry to muddy the waters.

Thanks again for finding the solution.

Regards,
Jason

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel