[Piglit] [PATCH] core: don't try to resolve the real path of the file

Ilia Mirkin imirkin at alum.mit.edu
Mon Feb 10 21:34:49 PST 2014


On Tue, Feb 11, 2014 at 12:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Tue, Feb 11, 2014 at 12:17 AM, Ken Phillis Jr <kphillisjr at gmail.com> wrote:
>> On Mon, Feb 10, 2014 at 9:15 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>> I may be showing signs of idiocy here, but... I don't at all
>>> understand what you're saying. Could you elaborate as to the specific
>>> example you have in mind where open(filename) differs from
>>> open(os.path.realpath(filename))? The example that I have is where
>>> "filename" is a fake symlink generated by the shell (or kernel, not
>>> sure), and dereferencing it is harmful. That's why I've removed the
>>> symlink dereference. In any other instance, open() would just follow
>>> the symlink just like realpath would...
>>>
>>>   -ilia
>>
>> The resolving of the real path is to resolve problems with relative
>> file paths and a system where the piglit's files and folders are read
>> only.
>
> Again... specific example, please :) I don't see how my change would
> affect whether that works or not.

To elaborate a bit on why I think I'm right, let me provide this example:

$ mkdir somepath
$ cat > somepath/script.py
import sys
print open(sys.argv[1], "r").read()
$ cat > testfile
testing
$ python somepath/script.py testfile
testing

Note that being able to read/write the "somepath" dir had absolute no
effect on anything. open() works relative to the cwd. (And so does
realpath, for that matter.)

  -ilia


More information about the Piglit mailing list