FileUtils.mv shouldn't try to make sure the owner is preserved
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.
Updated by jeremyevans0 (Jeremy Evans) almost 3 years ago
- 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.