fix: from FIXME(#24570) added more info

[WrldEngine]

Added more info from FIXME(#24570)

#24570 (comment)
Added fields like from unix version of rustc: read/write flags
And other additional field for debug.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[hkBst]

See comment

View changes since this review

[WrldEngine]

@hkBst Should you add labels for windows, or is this unnecessary for this time?

[hkBst]

@WrldEngine yes, I will, but you can do it yourself too.

@rustbot label O-windows
r? @ChrisDenton

[rustbot]

ChrisDenton is not on the review rotation at the moment.
They may take a while to respond.

[WrldEngine]

@WrldEngine yes, I will, but you can do it yourself too.

@rustbot +labels O-windows

r? @ChrisDenton

Got it. I thought that is the permission-related

[ChrisDenton]

This does not look correct to me. If you use File::create to create and open a write-only file this will claim it's readable when it is not. And a file opened only for reads may not have the readonly attribute set on the file itself.

[WrldEngine]

This does not look correct to me. If you use File::create to create and open a write-only file this will claim it's readable when it is not. And a file opened only for reads may not have the readonly attribute set on the file itself.

I will rewrite it for ACL
I thought that if I added this information, it would also not bad

[ChrisDenton]

I think what matters here is how the file was opened rather than permissions specifically. For example, on Linux this program:

fn main() { let f = std::fs::File::options() .read(false) .write(true) .create(true) .open("foo") .unwrap(); println!("{f:?}",); }

Produces this result:

File { fd: 3, path: "/playground/foo", read: false, write: true } 

So read is false because you can't read from the opened File. But you can reopen the file and read it.

[WrldEngine]

As i understand, you interested only in permission during using "session" of file descriptor, not permissions given by system (that i think will be also informative). So, if i add ACCESS_MASK (also add windows target binding from NtQueryObject and another impls) and add acl (via winapi GetSecurityInfo or other similar lower cost functions) to File struct as method file_acl (like file_attr) and finally bind to debug, would that be acceptable to you?

[ChrisDenton]

File attributes aren't really an analogue of file mode because they don't have much to do with permissions. That would be ACLs. In any case, what we care most about is how the opened file handle can be used, rather than what the on-disk file has set.

E.g. can I write to this file using this particular file handle? Can I read from the file handle? Attributes don't tell you this.

[WrldEngine]

In windows files readable as default, if attrs set to the readonly of course you cannot write to them and use file handler for writing, i don't get the point about examples part, for debugging this infromation useful, than just check you opened the file in write or read mode i think so

[ChrisDenton]

If the File was opened with write(false) you cannot write to it whatever the readonly attribute says.