Commit Graph

19 Commits

Author SHA1 Message Date
Dan Gohman
ce00b3e2e0 Use link on platforms which lack linkat. 2020-10-18 07:47:32 -07:00
Dan Gohman
23a5c21415 Fix a typo in a comment. 2020-10-18 07:21:41 -07:00
Dan Gohman
91a9f83dd1 Define fs::hard_link to not follow symlinks.
POSIX leaves it implementation-defined whether `link` follows symlinks.
In practice, for example, on Linux it does not and on FreeBSD it does.
So, switch to `linkat`, so that we can pick a behavior rather than
depending on OS defaults.

Pick the option to not follow symlinks. This is somewhat arbitrary, but
seems the less surprising choice because hard linking is a very
low-level feature which requires the source and destination to be on
the same mounted filesystem, and following a symbolic link could end
up in a different mounted filesystem.
2020-10-16 12:05:49 -07:00
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