On 9/1/20, Chris Angelico <ros...@gmail.com> wrote:
> On Wed, Sep 2, 2020 at 4:55 AM Eryk Sun <eryk...@gmail.com> wrote:
>
>> "test2/spam" is a bind mount for "test1/spam", and note that `mount
>> --bind` in Linux is a namespace operation, i.e. it's not a new device:
>>
>> >>> os.lstat('test1/spam').st_dev == os.lstat('test2/spam').st_dev
>> True
>> >>> os.lstat('test1/spam').st_ino == os.lstat('test2/spam').st_ino
>> True
>>
>> According to POSIX (st_dev, st_ino), it's the same directory, yet the
>> ".." entry evaluates depending on the path parsing context:
>>
>> >>> os.lstat('test1/spam/..').st_ino == os.lstat('test1').st_ino
>> True
>> >>> os.lstat('test2/spam/..').st_ino == os.lstat('test2').st_ino
>> True
>
> When you add ".." to the end of a path, it is very frequently handled
> textually. Can you do this exercise by actually opening the
> directories and then using openat or statat?
The Python example doesn't process the input path to normalize or
resolve it, so I assume you mean text-based processing in the kernel
for the lstat system call. I can switch to using dir_fd, which is
implemented via fstatat in Linux.
Showing again that the bind mountpoint is the same directory:
>>> fd1 = os.open('test1/spam', 0)
>>> fd2 = os.open('test2/spam', 0)
>>> fs1, fs2 = os.fstat(fd1), os.fstat(fd2)
>>> (fs1.st_dev, fs1.st_ino) == (fs2.st_dev, fs2.st_ino)
True
In agreement with the previous example, the ".." entry evaluates
depending on the original path parsing context of the opened fd:
>>> os.lstat('..', dir_fd=fd1).st_ino == os.lstat('test1').st_ino
True
>>> os.lstat('..', dir_fd=fd2).st_ino == os.lstat('test2').st_ino
True
--
https://mail.python.org/mailman/listinfo/python-list
