Commit Graph

16 Commits

Author SHA1 Message Date
Mara Bos
71bb1dc2a0 Take sys/vxworks/{fd,fs,io} from sys/unix instead. 2020-10-16 06:19:00 +02:00
Josh Stone
1d06b07765
simplify the cfg in ReadDir construction
Co-authored-by: David Tolnay <dtolnay@gmail.com>
2020-10-09 10:54:50 -07:00
Josh Stone
365e00aeee remove ReadDir.end_of_stream on targets that don't use it 2020-10-09 10:00:11 -07:00
Josh Stone
c1297eca3e unix/vxworks: make DirEntry slightly smaller
`DirEntry` contains a `ReadDir` handle, which used to just be a wrapper
on `Arc<InnerReadDir>`. Commit af75314ecd added `end_of_stream: bool`
which is not needed by `DirEntry`, but adds 8 bytes after padding. We
can let `DirEntry` have an `Arc<InnerReadDir>` directly to avoid that.
2020-10-09 10:00:11 -07:00
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