"File name too long" error occurs when attempting to assemble a project on an encrypted Linux machine

[JustAHappyKid]

Sorry in advance, as this is as much an OS/file-system limitation as it is a bug in the software, but devising some sort of workaround in this plugin (sbt-assembly) would seem the most practical route.

So, this seems to occur with any project that uses the newly-released Slick library. This is the library-dependency line:

"com.typesafe.slick" %% "slick" % "1.0.0"

Then, when running sbt assembly, you get something like this:

[error] (*:assembly) Error extracting zip entry 'scala/slick/compiler/ReplaceFieldSymbols$$anonfun$scala$slick$compiler$ReplaceFieldSymbols$$rewrite$1$3$$anonfun$apply$3$$anonfun$apply$5$$anonfun$apply$7$$anonfun$3.class' to '/home/chris/Desktop/simple-slick/target/scala-2.10/cache/default-9a0c39/global/assembly/8529d1f5a87909bfe3ce47bceecf3c9a5d0bb40e/scala/slick/compiler/ReplaceFieldSymbols$$anonfun$scala$slick$compiler$ReplaceFieldSymbols$$rewrite$1$3$$anonfun$apply$3$$anonfun$apply$5$$anonfun$apply$7$$anonfun$3.class': java.io.FileNotFoundException: /home/chris/Desktop/simple-slick/target/scala-2.10/cache/default-9a0c39/global/assembly/8529d1f5a87909bfe3ce47bceecf3c9a5d0bb40e/scala/slick/compiler/ReplaceFieldSymbols$$anonfun$scala$slick$compiler$ReplaceFieldSymbols$$rewrite$1$3$$anonfun$apply$3$$anonfun$apply$5$$anonfun$apply$7$$anonfun$3.class (File name too long)
[error] Total time: 6 s, completed Feb 27, 2013 11:07:33 AM

[jrudolph]

I don't think there's not much that sbt-assembly could improve to get around this error. Have you seen this thread:

https://groups.google.com/forum/?fromgroups=#!topic/simple-build-tool/wtD6vgdiy6g

You could try to use the scalac -Xmax-classfile-name setting.

[JustAHappyKid]

I went ahead and mocked up a script to sync-up my dependencies independently, upon deployment... So for my purposes, this can be ignored/closed.

But, FYI, to anyone else stumbling across this issue, the above-linked thread indicates that the problem arises when you're building from a home directory that's encrypted. Workarounds include making your target directory a sym-link to /tmp, and using -Xmax-classfile-name as suggested (by jrudolph).

[eed3si9n]

@jrudolph Thanks for answering this!

@JustAHappyKid I am assuming you're also on an encrypted Linux machine, so I renamed the case that way.

[JustAHappyKid]

@eed3si9n Yes that's correct -- I'm using an encrypted home directory (or at least recall checking that checkbox upon installation).

[jayden82821]

Long path tool can be very helpful on this situation. Thanks

[adamnovak]

"Long Path Tool" is a Windows-only program. It's not going to help on an encrypted Ubuntu mount.

[nickpoorman]

This isn't just encrypted machines. Docker has the limit as well. Anything that tries to use sbt-assemly in a Docker container could fail becuase of this.

[nightscape]

I'm just running into the same problem and the workarounds are not very handy...
Wouldn't it be an option if sbt-assembly just didn't write the files to disk? If it just kept them in memory (maybe via config option so it doesn't crash for large projects) and repacked them into the final jar from there then this problem wouldn't occur, right?
In that case one of these projects might be helpful:
https://github.com/marschall/memoryfilesystem
https://github.com/sbridges/ephemeralfs
https://github.com/google/jimfs
https://github.com/openCage/memoryfs

[adamnovak]

There's a workaround I remember I used to limit the length (although I
don't remember what it is). Maybe that length limit should be on/shorter by
default?

On Tue, Oct 27, 2015 at 3:57 PM, Martin Mauch notifications@github.com
wrote:

I'm just running into the same problem and the workarounds are not very
handy...
Wouldn't it be an option if sbt-assembly just didn't write the files to
disk? If it just kept them in memory (maybe via config option so it doesn't
crash for large projects) and repacked them into the final jar from there
then this problem wouldn't occur, right?

—
Reply to this email directly or view it on GitHub
#69 (comment).

[nightscape]

I guess you're referring to using -Xmax-classfile-name as a compiler option.
Unfortunately the implicit default value for this option is 255 which is bigger than the 242 that's supported by Docker.
So in my case, I'm trying to assemble a fat jar inside a Docker container (building jars inside a Docker container greatly simplifies your build-server) which fails due to the shapeless library having file names > 242 characters.
I could locally build a shapeless version with -Xmax-classfile-name=242, but that would be rather annoying and not solve the larger problem...

[janstenpickle]

Just came across this from some googling and just wanted to post a workaround for anyone having the same issue under docker, but not wanting to recompile third party libs.

I mounted a directory from the host server in the docker container using the -v switch, seeing as this volume is ext4 the assembly works as if it were outside docker.

(more info about mounting directories from the host can be found in the docker docs here)

[nightscape]

Ah, good idea @janstenpickle! I tried incorporating an in-memory FS into sbt-assembly but didn't get very far.

[JonathanTaws]

Can confirm that @janstenpickle suggestion to mount the directory on the host is a perfect workaround, worked like a charm. Thank you !