Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2017-08-31.09:55:01.045>labels= ['3.7', 'type-feature', 'library']
title='Feature Add support of os.chflags() on Linux platform'updated_at=<Date2017-09-01.09:27:54.508>user='https://github.com/socketpair'
FS_IOC flags are different from the stat.UF_* & stat.SF_* that os.chflags operates on.
If we add them, they should use a different function, perhaps in fcntl or around statx, or use the chattr name.
Feature proposals should go on Discourse nowadays; ideally with a use case.
Activity
socketpair commented on Aug 31, 2017
Yes, chflags() is not supported by linux directly. But actually, Linux supports chflags functionality:
https://stackoverflow.com/questions/34176464/why-os-chflags-doesnt-work-under-linux
through
ioctl (fd, EXT2_IOC_SETFLAGS, <BITMASK_OF_FLAGS>)
pitrou commented on Aug 31, 2017
Judging by the ioctl name, this is ext2/ext3/ext4 specific?
socketpair commented on Sep 1, 2017
Well, it seems, you are right.
But there are another ioctls (maybe they are the same, I haven't checked):
FS_IOC_SETFLAGS
FS_IOC_GETFLAGS
http://man7.org/tlpi/code/online/book/files/chiflag.c.html (also attached)
pitrou commented on Sep 1, 2017
On Ubuntu 16.04 I get the following values:
EXT2_IOC_SETFLAGS = 0x40086602, FS_IOC_GETFLAGS = 0x80086601
pitrou commented on Sep 1, 2017
Uh, of course, we care about SETFLAGS here. Which gives:
EXT2_IOC_SETFLAGS = 0x40086602, FS_IOC_SETFLAGS = 0x40086602
encukou commented on Aug 25, 2026
FS_IOC flags are different from the stat.UF_* & stat.SF_* that os.chflags operates on.
If we add them, they should use a different function, perhaps in fcntl or around statx, or use the chattr name.
Feature proposals should go on Discourse nowadays; ideally with a use case.