Timeline for Why do Linux/POSIX have lchown but not lchmod?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 26, 2015 at 20:58 | comment | added | schily | HP-UX permits to have symlink permissions other than 777 but the permissions are not evaluated. | |
| Aug 26, 2015 at 16:11 | comment | added | Stéphane Chazelas | @schilly, OS/X does honour permissions on symlinks. There, if you don't have read permissions, you can't resolve their targets. | |
| Aug 26, 2015 at 9:17 | comment | added | schily | Correct, as permissions of symlinks are not evaluated since 35 years, it makes no sense to change the modes. Fchmodat() exists for orthogonslity. The only real advantage was futimensat() as settable timestamps for symlinks help humans to understand a directory tree. | |
| Aug 25, 2015 at 23:04 | comment | added | muru | How so? The standard says: Some implementations might allow changing the mode of symbolic links. This is not supported by the interfaces in the POSIX specification. Systems with such support provide an interface named lchmod(). To support such implementations fchmodat() has a flag parameter. All this says is there's a flag for fchmodat that lets the implementation change symlink perms. Not that it necessarily can. | |
| Aug 25, 2015 at 23:01 | comment | added | schily | The op asked why only one of the functions is supported and I explained that virtually both are available, just not under the name mentioned. | |
| Aug 25, 2015 at 22:22 | comment | added | muru | OP knows not having lchmod is in accordance with POSIX. What does this answer add that is not already in the question? | |
| Aug 25, 2015 at 21:50 | history | answered | schily | CC BY-SA 3.0 |