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 renameat, AT_FDCWD #1097

Merged
merged 1 commit into from
Jul 18, 2019
Merged

Add renameat, AT_FDCWD #1097

merged 1 commit into from
Jul 18, 2019

Conversation

scottlamb
Copy link
Contributor

No description provided.

@scottlamb scottlamb force-pushed the pr-renameat branch 2 times, most recently from 09a9198 to 856c842 Compare July 11, 2019 23:46
Copy link
Member

@asomers asomers left a comment

Choose a reason for hiding this comment

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

PR #1058 is already adding unlinkat, so you should remove that from this PR.

src/fcntl.rs Outdated
pub fn renameat<P1: ?Sized + NixPath, P2: ?Sized + NixPath>(old_dirfd: RawFd, old_path: &P1,
new_dirfd: RawFd, new_path: &P2)
-> Result<()> {
let res = try!(try!(old_path.with_nix_path(|old_cstr| {
Copy link
Member

Choose a reason for hiding this comment

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

? is preferred over try!. It's supported by Nix's MSRV.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

src/fcntl.rs Outdated
@@ -164,6 +167,26 @@ pub fn openat<P: ?Sized + NixPath>(dirfd: RawFd, path: &P, oflag: OFlag, mode: M
Errno::result(fd)
}

pub fn rename<P1: ?Sized + NixPath, P2: ?Sized + NixPath>(old: &P1, new: &P2) -> Result<()> {
Copy link
Member

Choose a reason for hiding this comment

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

Is there any reason to use rename when renameat is supported? None that I know of.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

None that I know of either. I added it because I saw in other cases (such as open and openat directly above) both variants were there. Would you like me to remove it?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, you should remove it. Supporting legacy APIs in existing code makes sense, but much like CloudABI, we shouldn't add brand new APIs that are already legacy.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, and squashed my commits.

renameat(old_dirfd, "old", new_dirfd, "new").unwrap();
assert_eq!(renameat(old_dirfd, "old", new_dirfd, "new").unwrap_err(),
Error::Sys(Errno::ENOENT));
close(old_dirfd).unwrap();
Copy link
Member

Choose a reason for hiding this comment

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

How about a check that new_dir/"new" exists?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops. Done.

@scottlamb
Copy link
Contributor Author

Thanks for the review!

@scottlamb scottlamb force-pushed the pr-renameat branch 2 times, most recently from 0f4a321 to 8824118 Compare July 17, 2019 19:29
@asomers
Copy link
Member

asomers commented Jul 17, 2019

Sorry, but you'll need to rebase your branch on top of master, rather than merging master into your branch.

@scottlamb
Copy link
Contributor Author

Done. Sorry, not a real experienced git user.

@asomers
Copy link
Member

asomers commented Jul 17, 2019

It's ok; none of us are experienced git users. Basically nobody is. But it looks like you rebased onto a too-old version of master, and now there's a conflict in the CHANGELOG. Could you please update your master and rebase again?

@scottlamb
Copy link
Contributor Author

Is this better? I did:

$ git pull
$ git rebase master
$ git push -f

I tried something a little different before: first I did a merge from github's UI, then when you pointed out I needed a merge, I tried a git rebase -i, but perhaps I didn't pull again first? dunno.

@asomers asomers changed the title Add rename, renameat, AT_FDCWD Add renameat, AT_FDCWD Jul 17, 2019
@scottlamb
Copy link
Contributor Author

Hmm, actually, looks like #1058 had a different approach to AT_FDCWD of taking an Option<RawFd>. Since I merged past that PR, lemme modify mine to be consistent with that approach...

renameat is (somewhat oddly, imho) in stdio.h. I put it in
nix::fcntl because there's no nix::stdio and all its friends
(including the AT_* constants) are in nix::fcntl.
@scottlamb
Copy link
Contributor Author

Okay, now has an interface more consistent with #1058.

Copy link
Member

@asomers asomers left a comment

Choose a reason for hiding this comment

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

bors r+

bors bot added a commit that referenced this pull request Jul 18, 2019
1097: Add renameat, AT_FDCWD r=asomers a=scottlamb



Co-authored-by: Scott Lamb <slamb@slamb.org>
@bors
Copy link
Contributor

bors bot commented Jul 18, 2019

Build succeeded

@bors bors bot merged commit 6454a06 into nix-rust:master Jul 18, 2019
scottlamb added a commit to scottlamb/moonfire-nvr that referenced this pull request Jul 20, 2019
nix-rust/nix#1097 is merged so it does what we need now.
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.

2 participants