Refactored docs for std::fs::set_permissions_nofollow + fix BSD-based systems to use fchmodat with AT_SYMLINK_NOFOLLOW flag - #160170
Conversation
|
@bors r+ rollup |
|
@bors r- Sorry I have a question :) |
|
This pull request was unapproved. |
|
r? RalfJung since you're mostly reviewing already |
|
|
d24bee2 to
82ff1cb
Compare
std::fs::set_permissions_nofollow + fix BSD-based systems to use fchmodat with AT_SYMLINK_NOFOLLOW flag
82ff1cb to
f0403c2
Compare
|
The user-facing comments are fine but this is turning into a libs discussion about the implementation. r? libs |
|
@bors note="Multi-platform code, has been tried but known to be unreliable" rollup=iffy |
|
Unknown command "note". Run |
|
@bors r+ note="Multi-platform code, has been tried but known to be unreliable" rollup=iffy |
This comment has been minimized.
This comment has been minimized.
Refactored docs for `std::fs::set_permissions_nofollow` + fix BSD-based systems to use fchmodat with AT_SYMLINK_NOFOLLOW flag This PR refactors documentations for `std::fs::set_permissions_nofollow` and fixes BSD-based systems + Android to use `fchmodat` with `AT_SYMLINK_NOFOLLOW` flag (instead of no flag set) and refactors all other platforms to defer to `OpenOptions` with `O_NOFOLLOW` behavior. r? @clarfonthey Since they looked at the original `set_permissions_nofollow` PR I made cc @RalfJung
This comment has been minimized.
This comment has been minimized.
|
💔 Test for 9c04978 failed: CI. Failed job:
|
|
@rustbot author Looks like Android is still not working as intended. |
|
Reminder, once the PR becomes ready for a review, use |
459be4d to
eb1ceb9
Compare
|
@bors try jobs=dist-android,arm-android |
This comment has been minimized.
This comment has been minimized.
Refactored docs for `std::fs::set_permissions_nofollow` + fix BSD-based systems to use fchmodat with AT_SYMLINK_NOFOLLOW flag try-job: dist-android try-job: arm-android
|
💔 Test for 8c8e5d7 failed: CI. Failed job:
|
This comment has been minimized.
This comment has been minimized.
|
Seems like @clarfonthey is it alright to just have that test not run on android? |
|
Are you sure this isn't case 1 in that issue, i.e. it ended up changing the mode of the file the symlink points to and then declared success? |
If that is the case, that seems to be an incorrect behavior produced by From the bionics libc code (if that's the correct place to look at for android), I can only imagine that the |
|
I don't know, that's why I am asking you. ;) The test should assert that the read-only flag on the file the symlink points to is not changed by this call. |
eb1ceb9 to
da31cd7
Compare
…d fchmodat platform call on fchmodat and every platform falls back to open + fchmod when _res is set to ErrorKind::Unsupported; updated docs to reflect change
da31cd7 to
625be1f
Compare
Alright, well I adjusted the test case to check if our target file has the same permission bits before calling on @rustbot try jobs=dist-android,arm-android |
| let metadata = check!(fs::metadata(&symlink_name)); | ||
| let file_permission_bits = metadata.permissions(); |
There was a problem hiding this comment.
Please don't mix this in the middle of the other operations. The code is quite hard to follow now. Also the variable names could be more self-describing.
View all comments
This PR refactors documentations for
std::fs::set_permissions_nofollowand fixes BSD-based systems + Android to usefchmodatwithAT_SYMLINK_NOFOLLOWflag (instead of no flag set) and refactors all other platforms to defer toOpenOptionswithO_NOFOLLOWbehavior.r? @clarfonthey
Since they looked at the original
set_permissions_nofollowPR I madecc @RalfJung