grub-devel
[Top][All Lists]
Advanced

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

Re: Behavior of file test operations on symlinks


From: Alan Dunn
Subject: Re: Behavior of file test operations on symlinks
Date: Wed, 17 Feb 2016 12:19:01 -0800

On Wed, Feb 17, 2016 at 8:42 AM, Andrei Borzenkov <address@hidden> wrote:
17.02.2016 03:34, Alan Dunn пишет:
> Hi folks,
>
> Apologies if the following has already come up on this list; I looked for
> it and could not find any mention of it.
>
> I noticed that in a GRUB script "[ -f <dangling symlink path> ]" evaluates
> to true.  This is unlike the behavior of the "test" binary, in which it
> returns false: most file test operations dereference their symlinks
> recursively (i.e., strace on Linux reveals they use stat, which does
> this).  By contrast, "[ -s <dangling symlink path> ]" evaluates to false,
> which seems inconsistent since if the file exists by -f, then it seems like
> -f is referring to the symlink itself, which has non-zero file size.
>

It looks rather side effect of implementation which looks for directory
entry.

It is straightforward to fix it by just trying to grub_file_open() which
fails in this case. But the interesting question is semantic of both
tests with mandatory signature checking in place. I.e. if signature for
a file is invalid, should "test -s" and "test -f" still report true? I
suppose yes, because file still exists.

> I was curious whether there is some motivation with respect to any
> deviations that GRUB has in interpreting file test operations in comparison
> to the "test" binary, or whether this is considered a bug/thing that should
> be improved in the documentation.  The GRUB manual (
> http://git.savannah.gnu.org/cgit/grub.git/tree/docs/grub.texi) only
> indicates that -f tests whether the "file exists and is not a directory"

Well, current behavior is compliant with this description (symlink does
exist and it is not directory), it is just not very useful in practice.
Actually implementing "test -h" is pretty trivial.

> without specifying the symlink behavior (unlike "man test").
>

I vote for changing it to follow symlink. Anyone has argument to keep
current behavior?

If I were going to design GRUB's behavior, I would make all file-related tests that GRUB implements (-d, -e, -f, -s, -nt, -ot) follow symlinks, like test in coreutils does, for consistency.  If that sounds reasonable to the list, I'm happy to try to produce such a patch.  Offhand, it seems like the basic strategy would be to modify get_fileinfo (in grub-core/commands/test.c) to follow symlinks.


_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]