Message369071
There's no reason this can't be generalized to file attributes/flags on other platforms such as st_flags on BSD/macOS and st_attributes on Linux (depending on bpo-39533 -- but statx only returns a small subset of attributes that are available via chattr and lsattr).
Here's a table of approximately corresponding file attributes in BSD, Linux, and Windows:
BSD [1] Linux Windows
------------------------------------------------------------------------
UF_NODUMP STATX_ATTR_NODUMP -d
UF_APPEND STATX_ATTR_APPEND -a
STATX_ATTR_ENCRYPTED -E FILE_ATTRIBUTE_ENCRYPTED -E
UF_COMPRESSED STATX_ATTR_COMPRESSED -c FILE_ATTRIBUTE_COMPRESSED -C
UF_IMMUTABLE STATX_ATTR_IMMUTABLE -i FILE_ATTRIBUTE_READONLY -R [2]
UF_NOUNLINK FILE_ATTRIBUTE_READONLY -R [2]
UF_READONLY FILE_ATTRIBUTE_READONLY -R
UF_HIDDEN FILE_ATTRIBUTE_HIDDEN -H
UF_SYSTEM FILE_ATTRIBUTE_SYSTEM -S
UF_ARCHIVE FILE_ATTRIBUTE_ARCHIVE -A
UF_SPARSE FILE_ATTRIBUTE_SPARSE_FILE -P
UF_REPARSE FILE_ATTRIBUTE_REPARSE_POINT -L
UF_OFFLINE FILE_ATTRIBUTE_OFFLINE -O
[1] Not supported on all BSD platforms, including macOS.
[2] Readonly applies to regular file data, not metadata or directory
contents (index data). Also, it disallows unlink but allows rename.
> not surprisingly I miss all windows attributes. On the top of that I
> get only values of stat.S_IWRITE and stat.S_IREAD as documented in
> os.chmod().
Windows doesn't implement a direct equivalent of the Unix file mode. But Windows file attributes partially overlap the Unix file mode for the S_IFMT filetype bits. In particular, WinAPI GetFileType classifies an open file based on the device type as one of FILE_TYPE_CHAR (S_IFCHR), FILE_TYPE_PIPE (S_IFIFO, S_IFSOCK), or FILE_TYPE_DISK (S_IFBLK, S_IFREG, S_IFDIR, S_IFLNK). For the latter, FILE_ATTRIBUTE_DIRECTORY and FILE_ATTRIBUTE_REPARSE_POINT distinguish S_IFDIR and reparse points, including S_IFLNK, depending on the reparse tag. The lack of either attribute indicates S_IFREG, and no support for file attributes indicates S_IFBLK. For example:
>>> stat.filemode(os.stat('//./nul').st_mode) # S_IFCHR
'c---------'
>>> stat.filemode(os.stat('//./pipe').st_mode) # S_IFIFO
'p---------'
>>> stat.filemode(os.stat('//./C:').st_mode) # S_IFBLK
'b---------'
(Apparently, we aren't fabricating any bogus permissions for the above cases.)
Free of charge, you also get a hack that sets the execute bit on directories, and also on files that have a file extension in the set {".COM", ".EXE", ".BAT", ".CMD"}. Caveat emptor: this has nothing to do with whether the file or directory actually grants the caller execute access.
>>> stat.filemode(os.stat('C:/').st_mode) # S_IFDIR
'drwxrwxrwx'
>>> os.stat('C:/Temp/spam.bat').st_file_attributes & stat.FILE_ATTRIBUTE_READONLY
1
>>> os.readlink('C:/Temp/symlink.bat')
'spam.bat'
>>> stat.filemode(os.lstat('C:/Temp/symlink.bat').st_mode) # S_IFLNK
'lrwxrwxrwx'
>>> stat.filemode(os.stat('C:/Temp/symlink.bat').st_mode) # S_IFREG
'-r-xr-xr-x'
Regarding the permission mode bits, many environments (including Python) misuse FILE_ATTRIBUTE_READONLY as a write permission, i.e. readonly removes the S_IWUSR | S_IWGRP | S_IWOTH bits. Certainly readonly should be a factor in os.access(), but it is not a permission; no one can be granted permission to write to a readonly file. Using it as such is inconsistent with UF_IMMUTABLE in BSD and STATX_ATTR_IMMUTABLE in Linux. It's also inconsistent with how write permission works in Unix, since readonly disallows deleting the file, which has nothing to do with write permission on a file in Unix. |
|
Date |
User |
Action |
Args |
2020-05-16 22:09:58 | eryksun | set | recipients:
+ eryksun, scrool |
2020-05-16 22:09:58 | eryksun | set | messageid: <1589666998.55.0.568709813825.issue40644@roundup.psfhosted.org> |
2020-05-16 22:09:58 | eryksun | link | issue40644 messages |
2020-05-16 22:09:58 | eryksun | create | |
|