make-temporary-{file,directory}{,*}: add #:permissions

[LiberalArtist]

This commit depends on #3870 and a hypothetical #:permissions argument to copy-file,where (copy-file #:permissions #f . args) would be the default and preserve the current behavior, i.e. copying the permissions of the source file.

For more thoughts on changes to copy-file, see: #3870 (comment) and #3870 (comment).

Before merging, it would also need to add tests.

[mflatt]

So far, I don't think copy-file should have a permissions argument. It seems like the main use of having a file to copy would be to get its attributes along with its content.

Adding #:permissions to make-temporary-file seems like a good addition, and those permissions could be used only when a source file to copy isn't specified.

Meanwhile, the problem with permissions on the intermediate file state in copy-file needs to be fixed. Does it work to use the original file's mode when creating the file, so in combination with umask, the copy starts out with permissions bounded by the original? The original file's permissions could then be applied afterward, in case that adds bits that umask dropped. Does it matter whether the final permissions are applied before or after the content is copied? (I lean toward keeping it after.)

[LiberalArtist]

I've rebased, since #3870 was merged, but I haven't tackled the test failures of other issues.

So far, I don't think copy-file should have a permissions argument. It seems like the main use of having a file to copy would be to get its attributes along with its content.

Adding #:permissions to make-temporary-file seems like a good addition, and those permissions could be used only when a source file to copy isn't specified.

I don't have a strong view on permissions for copy-file, and it doesn't seem to be common in other languages has me leaning not going that route.

The option I like the least is having make-temporary-file silently ignore #:permissions when #:copy-from is a file path. Currently, I'm leaning toward keeping #f as the context-sensitive default permissions (since the default has to be context-sensitive for 'directory mode, anyway) and raising an exception if non-#f permissions are given together with a file to be copied. I'm also inclined to have make-temporary-directory and make-temporary-directory* accept #f for consistency, but I'm not entirely convinced about that.

Meanwhile, the problem with permissions on the intermediate file state in copy-file needs to be fixed. Does it work to use the original file's mode when creating the file, so in combination with umask, the copy starts out with permissions bounded by the original? The original file's permissions could then be applied afterward, in case that adds bits that umask dropped. Does it matter whether the final permissions are applied before or after the content is copied? (I lean toward keeping it after.)

Intuitively, this seems reasonable to me, with the caveat that making temporary files seems to involve a lot of thorny intuitive issues. I don't remember having seen another language with a combined operation to make a temporary file by copying.

Would this change the handling of extended attributes?

If the source file has execute permissions, would it be an issue to have the execute permission set on the partial copy?

I guess I could imagine initializing the copy with minimal permissions (i.e. only user-read-bit) and applying the final permissions after copying the content. I'm not sure what the pros and cons would be.

[racket-discourse-github-bot]

This pull request has been mentioned on Racket Discussions. There might be relevant details there:

https://racket.discourse.group/t/umask-set-default-file-permissions/613/6

[LiberalArtist]

I was reminded by #4357 of the idea of #:permissions for copy-file, though I don't think it has persuaded me that it would really be a good idea.

[LiberalArtist]

I think a change analogous to 0ddb776 should fix this, and I hope to try that relatively soon.