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

add more *at functions. #562

Closed
wants to merge 10 commits into from
Closed

add more *at functions. #562

wants to merge 10 commits into from

Conversation

Mic92
Copy link
Contributor

@Mic92 Mic92 commented Mar 26, 2017

No description provided.

@Mic92 Mic92 force-pushed the atfamily branch 2 times, most recently from 0c43c15 to b7fa4c0 Compare March 27, 2017 12:44
@Mic92
Copy link
Contributor Author

Mic92 commented Mar 30, 2017

That's all folks. I have all methods for my fuse.

@Mic92 Mic92 force-pushed the atfamily branch 5 times, most recently from 98eb8a0 to 6077eef Compare April 5, 2017 15:03
@kamalmarhubi
Copy link
Member

@Mic92 this is heroic. I'm going to take a look over the weekend. Sorry for the delay!

@kamalmarhubi
Copy link
Member

I retried the failing test and it works now so that's a plus.

@Mic92
Copy link
Contributor Author

Mic92 commented Apr 8, 2017

I would also add large file support to all methods in a second pull request (64bit fields on 32-bit systems), to align the with glibc/musl/rust. Ideally this should be done before the next release.

@homu
Copy link
Contributor

homu commented Apr 15, 2017

☔ The latest upstream changes (presumably #536) made this pull request unmergeable. Please resolve the merge conflicts.

@posborne
Copy link
Member

posborne commented Apr 16, 2017

This is great @Mic92, just needs a rebase by the looks of it (the curse of the changelog). The only thing I would add is that we have been trying to add docs to more of the functions we are adding. I do not think this is a blocker for getting this included but would be a nice bonus for this change or a future PR.

E.g. Docs for fork: https://github.com/nix-rust/nix/blob/master/src/unistd.rs#L47. The main value is providing a quick link to relevant man pages and a quick overview (some of the names of the functions are somewhat cryptic).

@lucab
Copy link
Contributor

lucab commented Apr 24, 2017

I have a doubt on this (and on other fn taking RawFd in this crate): are all these functions just taking ownership of (a copy of) the fd or borrowing it? I think these all do an implicit copy+own of the RawFd (as it is just an alias to an int), and I fear this doesn't really guarantee that the fd has not been closed/dropped in the meanwhile by a close().

I'm not sure if it is a valid concern or not, but shouldn't all these functions take a &RawFd (and perhaps RawFd be made non-Copy)?

@kamalmarhubi
Copy link
Member

@lucab this is a real concern, and I agree that we should do what you suggest. We cannot change RawFd as it's part of the standard library. But we should change all RawFd parameters to take references, or something at least that safe. I've opened #594 to track it. Thanks for raising this!

@Mic92
Copy link
Contributor Author

Mic92 commented Jun 3, 2017

A reference does not buy you anything: https://play.rust-lang.org/?gist=1739781faf61fcec4afaf65bbaadd968&version=stable&backtrace=0
An not copyable type would destroy the semantics of some system calls like renameat, as it would no longer allow to pass the same directory twice.

@Mic92
Copy link
Contributor Author

Mic92 commented Jun 3, 2017

Merge conflict resolved. Man page references added.

src/unistd.rs Outdated
@@ -356,6 +375,13 @@ pub fn getcwd() -> Result<PathBuf> {
}
}

// According to the POSIX specification, -1 is used to indicate that
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment doesn't make sense here. Probably want to put it back in the function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I use this function in four different flavors of chown. Should I copied the comment to each of them? Why it does not make it sense here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because you're referring to uid_t and gid_t which aren't used in this function. The description to this should be more broad (not referring to those specific use cases) and then you can put comments stating why you need to use this function at the call site that refers to specific variables.

src/sys/stat.rs Outdated
@@ -53,6 +55,7 @@ bitflags! {
}
}


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This extra line should be removed.

src/unistd.rs Outdated
@@ -601,6 +672,69 @@ pub fn lseek64(fd: RawFd, offset: libc::off64_t, whence: Whence) -> Result<libc:
Errno::result(res).map(|r| r as libc::off64_t)
}

/// call the link function to create a link to a file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please capitalize the first word and add a period to the end of the first line of all these doc comments. If you run cargo doc --no-deps --open you can easily review their appearance to make sure things look good there.

src/sys/stat.rs Outdated

/// Change file timestamps with nanosecond precision
/// (see [utimensat(2)](http://man7.org/linux/man-pages/man2/utimensat.2.html))
pub fn utimensat<P: ?Sized + NixPath>(dirfd: RawFd,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dirfd and pathname actually combo together to form a ternary input type: one allowing a RawFd, another a relative path from the current working directory, and a third using an absolute path. I think we should use a ternary enum type here instead of the dirfd and pathname inputs to make this function call safer.

src/sys/stat.rs Outdated
use sys::time::TimeSpec;

pub enum UtimeSpec {
Now,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This enum is public and as such needs docs.

@Mic92 Mic92 force-pushed the atfamily branch 3 times, most recently from 2449a0c to b3a3a25 Compare June 3, 2017 22:40
@Susurrus
Copy link
Contributor

Susurrus commented Jun 4, 2017

There a common theme through a lot of these functions of having a dirfd and a path that is a tristate:

  • The dirfd is ignored if path is absolute
  • If dirfd is AT_FDCWD and path is relative it's resolved relative to the CWD
  • If path is relative and dirfd isn't AT_FDCWD then the path is resolved relative to that path.

I'm thinking an enum encompassing these states would be better instead of having two separate variables. I think an ideal solution would be to have NixPath have an Absolute and Relative mode or something to that effect, but for this PR I think just having an enum with different types is good enough.

use std::os::unix::prelude::AsRawFd;
use tempfile::NamedTempFile;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please put non-std/core imports down in their own group.

src/sys/stat.rs Outdated
Now,
/// The corresponding file timestamp is left unchanged.
Omit,
Time(TimeSpec)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one needs a comment too.

src/sys/stat.rs Outdated
Time(TimeSpec)
}

fn to_timespec(time: &UtimeSpec) -> libc::timespec {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a doccomment for this function? Nix devs should know if they can or should use it elsewhere in this function.

CHANGELOG.md Outdated
- Added `nix::unistd::{openat, fstatat, readlink, readlinkat, rename, renameat, mknodat}`
([#551](https://github.com/nix-rust/nix/pull/551))
- Added `nix::unistd::{openat, fstatat, readlink, readlinkat, rename, renameat, mknodat, unlinkat}`
([#497](https://github.com/nix-rust/nix/pull/551))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the PR numbering change he was intentional.

@Mic92 Mic92 force-pushed the atfamily branch 3 times, most recently from 61a42c0 to 6aa502e Compare June 5, 2017 05:47
@Mic92
Copy link
Contributor Author

Mic92 commented Jun 5, 2017

@Susurrus do you want to implement that enum for these functions send me a pull request? I don't see how Rust's typesystem is expressive enough to ensure a path is always relative/absolute without runtime checks.

@Susurrus
Copy link
Contributor

Susurrus commented Jun 5, 2017

My suggestion is to have a:

pub enum AtPath {
  AbsPath(NixPath),
  RelativeTo(RawFd, NixPath),
  RelativeCwd(NixPath),
}

Now we could add runtime checks through having some conversion path from NixPaths to this enum and I think that's the most ergonomic, which would be ideal, and if you'd like to implement something like that we can spec it out here. But at least with this enum it's more clear to the user what combinations of inputs are valid.

@Susurrus
Copy link
Contributor

Susurrus commented Jun 5, 2017

I wanted to point out that I also preferred the arguments @bugaevc who was working on access/faccessat in #605. There they came up with a dual-state enum for use with those functions that looks like:

pub enum AccessFlags {
  FileExists,
  FileExistsAndPermissions(PermFlags),
}

where PermFlags are the R_OK, etc. constants. I'd prefer having that than the regular libc-like constants.

@Susurrus
Copy link
Contributor

@Mic92 I wanted to circle back to this and see if we could get this merged? I'm working on some stuff in fcntl but it should get merged within a day or so. Then I'd like to get this PR merged if possible. Still willing to push this through?

@Mic92
Copy link
Contributor Author

Mic92 commented Aug 22, 2017

I am back from holiday on Thursday.

@lucab
Copy link
Contributor

lucab commented Sep 6, 2017

What happened to this?

@Mic92
Copy link
Contributor Author

Mic92 commented Sep 6, 2017

I made multiple pull requests out of it.

@oblique oblique mentioned this pull request Dec 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants