Bug #9850: FileUtils.mv shouldn't try to make sure the owner is preserved

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN

[rosenfeld (Rodrigo Rosenfeld Rosas)]

I found an issue with one of our servers due to user ids not being mapped correctly between the NFS server and client. In the NFS server side there was a settings to consider anonymous users as an specific user and that worked fine for a while.

When we came with a different implementation that writes documents to a temp dir, process them and move to the target directory I found that it wouldn't work on the server for which the owner of the mounted NFS export was set to nobody.

I consider this a bug because running "mv" on the Linux server wouldn't trigger any errors but FileUtils.mv will try to "chown" after moving the file and I don't think it should do anything different from simply moving the file.

I had to spend some time fixing the user id mapping on that server to fix the problem but I thought it would be a good thing to do to report this issue since this may be considered a bug of FileUtils.mv.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Feedback

FileUtils.mv does rescue EPERM failures in File.chown for the newly created file if it is on a different file system, and it did so in Ruby 2.1. Ruby now also rescues EACCESS failures in File.chown. This behavior should be similar to the mv command, as mv attempts to copy permissions as well, so I'm not sure why mv worked for you but FileUtils.mv did not.

If there was some other exception raised, I suppose we could handle it as well. However, we would probably need a backtrace in order to know where such an exception should be rescued, in order to determine how to fix it.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Feedback to Closed