Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding lchown to Unix #6877

Closed
vicuna opened this issue May 23, 2015 · 1 comment
Closed

Adding lchown to Unix #6877

vicuna opened this issue May 23, 2015 · 1 comment

Comments

@vicuna
Copy link

vicuna commented May 23, 2015

Original bug ID: 6877
Reporter: jcourant
Status: confirmed (set by @damiendoligez on 2015-06-15T15:28:07Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.02.1
Category: otherlibs
Tags: patch
Monitored by: jcourant @gasche

Bug description

Hi,

I wish lchown were available in the Unix module. As man lchown says: "lchown() is like chown(), but does not dereference symbolic links." (linux slackware, 14.1).

I had to use it for a pet project.

The most difficult part for me was to figure out how to find the version of otherlibs/unix/chown.c matching my binary distribution (actually, I switched to the latest compiler version instead), then it was just a matter of doing

sed -e 's/chown/lchown/g' -e 's|"unixsupport.h"|<caml/unixsupport.h>|" < chown.c > lchown.c

then adding external lchown : string -> int -> int -> unit = "unix_lchown" in my ml source.
It seems to work, at least for me, on my slackware (I did not attempt at testing other systems).

BTW, I also miss the lutimes function...

Yours,

Judicaël Courant.

PS: the man page also says:

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

fchown(), lchown():
_BSD_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
|| /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L

so I guess that means it is pretty standard.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 11, 2020
@stedolan stedolan self-assigned this May 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants