Commit Graph

12 Commits

Author SHA1 Message Date
Joshua Nelson
15f08d6ddf Revert "Function to convert OpenOptions to c_int" 2020-09-22 23:07:30 -04:00
bors
e0bc267512 Auto merge of #76110 - FedericoPonzi:convert-openoptions-cint, r=JoshTriplett
Function to convert OpenOptions to c_int

Fixes: #74943
The creation_mode and access_mode function were already available in the OpenOptions struct, but currently private. I've added a new free functions to unix/fs.rs which takes the OpenOptions, and returns the c_int to be used as parameter for the `open` call.
2020-09-22 13:02:02 +00:00
Federico Ponzi
321b680fe6 Update docs of OpenOptions::as_flags 2020-09-02 10:48:11 +02:00
Federico Ponzi
7c1e5c1dcd Update OpenOptions::as_flags docs, and minor styling 2020-08-31 23:20:56 +02:00
Federico Ponzi
2c9e27b759 Merge branch 'convert-openoptions-cint' of github.com:FedericoPonzi/rust into convert-openoptions-cint 2020-08-31 16:02:12 +02:00
Federico Ponzi
1bc0627607 Add as_flag function to the OpenOptionsExt struct 2020-08-31 15:48:28 +02:00
Federico Ponzi
eb3906be4a Fix typo get openoptions function name
Co-authored-by: Ivan Tham <pickfire@riseup.net>
2020-08-30 17:01:20 +02:00
Federico Ponzi
27c90b881d initial implementation of OpenOptions to c_int 2020-08-30 16:27:08 +02:00
The8472
4ddedd5214 perform copy_file_range until EOF is reached instead of basing things on file size
This solves several problems

- race conditions where a file is truncated while copying from it. if we blindly trusted
  the file size this would lead to an infinite loop
- proc files appearing empty to copy_file_range but not to read/write
  https://github.com/coreutils/coreutils/commit/4b04a0c
- copy_file_range returning 0 for some filesystems (overlay? bind mounts?)
  inside docker, again leading to an infinite loop
2020-08-14 22:41:13 +02:00
The8472
f0783632d3 more concise error matching 2020-08-12 20:09:55 +02:00
The8472
1316c786a0 Workaround for copy_file_range spuriously returning EOPNOTSUPP when attemted on a NFS mount under RHEL/CentOS 7.
The syscall is supposed to return ENOSYS in most cases but when calling it on NFS it may leak through
EOPNOTSUPP even though that's supposed to be handled by the kernel and not returned to userspace.
Since it returns ENOSYS in some cases anyway this will trip the  HAS_COPY_FILE_RANGE
detection anyway, so treat EOPNOTSUPP as if it were a ENOSYS.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.8_release_notes/deprecated_functionality#the_literal_copy_file_range_literal_call_has_been_disabled_on_local_file_systems_and_in_nfs
https://bugzilla.redhat.com/show_bug.cgi?id=1783554
2020-08-12 01:30:22 +02:00
mark
2c31b45ae8 mv std libs to library/ 2020-07-27 19:51:13 -05:00