GH-125413: Add private metadata methods to pathlib.Path.info

[barneygale]

Add the following private methods to pathlib.Path.info:

• _posix_permissions(): the POSIX file permissions (S_IMODE(st_mode))
• _file_id(): the file ID ((st_dev, st_ino))
• _access_time_ns(): the access time in nanoseconds (st_atime_ns)
• _mod_time_ns(): the modify time in nanoseconds (st_mtime_ns)
• _bsd_flags(): the BSD file flags (st_flags)
• _xattrs(): the file extended attributes as a list of key, value pairs, or an empty list if listxattr() or getxattr() fail in an ignorable way.

These methods replace LocalCopyReader.read_metadata(), and so we can delete the CopyReader and LocalCopyReader classes. Rather than reading metadata via source._copy_reader.read_metadata(), we instead call source.info._posix_permissions(), _access_time_ns(), etc.

Preserving metadata is only supported for local-to-local copies at the moment. To support copying metadata between arbitrary ReadablePath and WritablePath objects, we'd need to make the new methods public and documented.

• Issue: Expose os.DirEntry objects from pathlib #125413

[encukou]

Should _file_id return a (st_dev, st_ino) tuple? AFAIK, separating them is only due to a low-level detail (you don't need to store st_dev on the disk).

---

To support copying metadata between arbitrary ReadablePath and WritablePath objects, we'd need to make the new methods public and documented.

Is that the plan?

It seems to me that people will want their subclasses to support such copying, and are might resort to underscored functions to get it.

[barneygale]

Should _file_id return a (st_dev, st_ino) tuple? AFAIK, separating them is only due to a low-level detail (you don't need to store st_dev on the disk).

Sounds good to me. Would we (eventually) document it as returning (st_dev, st_ino), or should we just say "some comparable/hashable object"?

Is that the plan?

It seems to me that people will want their subclasses to support such copying, and are might resort to underscored functions to get it.

Yes, I think it will be part of the PEP for making Joinable/Readable/WritablePath public.

[encukou]

Sounds good to me. Would we (eventually) document it as returning (st_dev, st_ino), or should we just say "some comparable/hashable object"?

The tuple for the local FS†, a comparable/hashable object in general?
† (Not sure if there's something better for Windows?)

I can imagine a path class that would add extra functionality to Path (or limit the functionality), but expose local files.

[barneygale]

Thanks :) I've deleted _device_id(), and made _file_id() return (st_dev, st_ino)

[barneygale]

Thanks for the review!