Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Reducing ActiveSupport::Cache::FILENAME_MAX_SIZE to 116 to support ecryptfs #7806

wants to merge 1 commit into from

4 participants


I have just tried to run rake within rails/activesupport (on master)

That generated

Errno::ENAMETOOLONG: File name too long - /home/jarl/projects/rails/activesupport/tmp_cache/5F0/AEA/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    /home/jarl/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:247:in `mkdir'
    /home/jarl/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:247:in `fu_mkdir'
    /home/jarl/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:221:in `block (2 levels) in mkdir_p'
    /home/jarl/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:219:in `reverse_each'
    /home/jarl/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:219:in `block in mkdir_p'
    /home/jarl/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:205:in `each'
    /home/jarl/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:205:in `mkdir_p'
    /home/jarl/projects/rails/activesupport/lib/active_support/cache/file_store.rb:161:in `ensure_cache_path'
    /home/jarl/projects/rails/activesupport/lib/active_support/cache/file_store.rb:90:in `write_entry'
    /home/jarl/projects/rails/activesupport/lib/active_support/cache/strategy/local_cache.rb:140:in `write_entry'
    /home/jarl/projects/rails/activesupport/lib/active_support/cache.rb:368:in `block in write'
    /home/jarl/projects/rails/activesupport/lib/active_support/cache.rb:525:in `instrument'
    /home/jarl/projects/rails/activesupport/lib/active_support/cache.rb:366:in `write'
    /home/jarl/projects/rails/activesupport/test/caching_test.rb:384:in `test_really_long_keys'

I googled a bit and discovered that ecryptfs has a much lower limitation on filename length (approximately 143 characters):

That basically means that running a rails app on an ecryptfs will
fail in a situation where the key is rather long.

If rails is supported on ecryptfs the
ActiveSupport::Cache::FILENAME_MAX_SIZE must be reduced to 116


@rafaelfranca @fxn any thoughts?


I'm not sure if this should be fixed on Rails. If you are using ecryptfs you should change the value in your application.

ActiveSupport::Cache::FILENAME_MAX_SIZE = 116 in some initializer could fix it.


:+1: on @rafaelfranca comment, we shouldn't change the default to support such specific cases and so I'm closing this.


@rafaelfranca : Good point that it can be set per application.

I agree with your conclusion. It is not the responsibility of Rails to support specific file systems. To be honest I think actually that it is a problem with eCryptFS (not with Rails) that it has such a rather low limitation on file name size as 143 opposed to many other file systems which has a limit on 255 (and some even no limit at all). However I would like to emphasize some things:

  1. I ran into this because I was hacking rails in my home dir (which is eCryptFS), so developing Rails is not recommended/supported on eCryptFS.
  2. People running Rails application in production on eCryptFS (maybe due to privacy/security/encryption policies) will not discover this problem until it is too late.

Point 1 is not a big issue... But regarding point 2: is there anything that can be done to warn these people (I am not one of them) earlier than "too late". Maybe emphasize in release notes or warning in the log at application boot or something else. A warning at boot time could be done by probing the file system being capable of creating files with names up to 255 characters. Such probe will not be eCryptFS specific but will just examine the file system capability in general. Kind of like using file_system.respond_to? :create_file_name_up_to_255_characters in the boot process before exploiting that capability later on during run-time. Or should these poor people installing Rails apps on eCryptFS just experience the issue with the flawed file system the hard way?


Maybe a warn in the docs of ActiveSupport::Cache?


I think a warn in the docs is good. Feel free to change it directly in the

@bamnet bamnet referenced this pull request in concerto/concerto

Frontend Image Rendering Fails - ENAMETOOLONG #471

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Sep 30, 2012
  1. @jarl-dk

    Reducing ActiveSupport::Cache::FILENAME_MAX_SIZE to 116 to support ec…

    jarl-dk committed
    where the maximum filename length is approximately 143 (see
This page is out of date. Refresh to see the latest.
Showing with 1 addition and 1 deletion.
  1. +1 −1  activesupport/lib/active_support/cache/file_store.rb
2  activesupport/lib/active_support/cache/file_store.rb
@@ -12,7 +12,7 @@ class FileStore < Store
attr_reader :cache_path
- FILENAME_MAX_SIZE = 228 # max filename size on file system is 255, minus room for timestamp and random characters appended by Tempfile (used by atomic write)
+ FILENAME_MAX_SIZE = 116 # max filename size on file system is normally 255 (but 143 on ecryptfs), minus room for timestamp and random characters appended by Tempfile (used by atomic write)
EXCLUDED_DIRS = ['.', '..'].freeze
def initialize(cache_path, options = nil)
Something went wrong with that request. Please try again.