Fixes #8095. For reference, here is the discussion about the mapping being incorrect: http://rubyforge.org/pipermail/tzinfo-users/2012-November/000114.html
It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.
Previously this code just assumed it is capable of changing the file ownership, both user and group. This will fail in a lot of scenario's unless: * The process is run as a superuser (root); * The owning user and group are already set to the user and group we're trying to chown to; * The user chown'ing only changes the group to another group it is a member of. If either of those conditions are not met the filesystem will simply deny the operation throwing an error. It is also not always possible to do a chmod, there might be a SELinux policy or another limitation preventing the user to change the file mode. To this end the chmod call has also been added to the rescue block. I've also added a little comment above the chmod command that doing a chmod on a file which has an ACL set will cause the ACL to be recalculated / modified.
It was noticed while profiling 'assets:precompile' in JRuby that exception creation was consuming a large portion of time, and some of that was due to File.atomic_write. Testing first with File.exists? eliminates the need for an exception which should be a perfomrance improvement on both JRuby and MRI. In this case, the stat() isn't even extra overhead, since it is always called.
Fixing the build.
rather than exiting the process.
This file is used at least by Active Merchant, its existence is maybe not necessary but no big deal either. This reverts commit ae9b3d7.
…ain queues in the classes that use them instead.
…e_condition_ttl working correctly.
…g to upgrade cache