Sometimes you "get away with it" and sometimes not! The command line version may use different memory allocation than some other version - this is in any event, "fragile" code that depends upon being lucky!

It appears to me that (a) you have a relatively small number of paths (70), that need to be shorted by a very modest amount - at least 3 chars, but I would try to go more than that for later expansion.

You could build a translation table. Say shortening "persistence-dom" to just "persistD". That alone would solve your immediate problem and get total path characters to less than 255. Throw some other translations in there and you can get to less than 200 chars.

There is a post in this node about "subst" which is one way to implement the "mount point" idea that I suggested earlier, and that is one way to go.

There is also a post that suggests an obvious solution: Don't generate path's with more than 255 chars! Explain to your users why this is important and a big pain in the ass to deal with and they will understand it.

The best solution is that everybody generates stuff that is easy to deal with, understands what the rules are, and why that makes sense. I would counsel you to get out of the file path/name translation business. If you don't, this will be a never ending assignment for you. In short, talk to your users, explain what grief this causes and some simple steps that they can do which eliminates this grief and is better for everybody.

There is also a post that suggests an obvious solution: Don't generate path's with more than 255 chars! Explain to your users why this is important and a big pain in the ass to deal with and they will understand it.

Oh gee, sure, I never thought of that suggestion. *eyerolling*. I have on numerous occasions suggested to the java dingleberry developers I work with that perhaps having a class called "findthefarmerwhohasthemostacerageandaskhimifhedliketobuyatractor.java" might be a candidate for abbreviation.

Apparently making me happy and their own lives less complicated is not their priority.

I created a hash in the code I added to my original post to do the very thing you suggest, a substitution table.
Unfortunately I can't seem to get the substitute command to actually do the job.

I will try your stat suggestion and hopefully that will give me help.

Thank you for responding with a thoughtful and very readable answer btw.

Hi! I didn't mean to sound flippant.

I've used this "translation table" idea before in a number of different contexts. In this context, I would split the path name into name tokens (stuff between /'s). Apply the translator to the dir names, if and only if it is a complete match to your translation table. Don't substitute on partial strings. Then reassemble the path name using join().

You have no chance to fiddle with the final target: "findthefarmerwhohasthemostacerageandaskhimifhedliketobuyatractor.java", BUT along the way to this end file target, there will be perhaps, "thisisaclassoffolkswhoarefarmersandtheirmothersmadiennamewaswoo_hoo /findthefarmerwhohasthemostacerageandaskhimifhedliketobuyatractor.java". I put a space after woo_hoo for display purposes.

I would think that these Java folks have some naming convention for these intermediate directories - that is the target of your translation table. Probably just a handful of these names shortened to other names will do it. One trick is that you want to be able to translate in both directions.

I wish you well. This is a mess when the other folks won't cooperate at least to a small extent. You have my sympathy.

In a completely general case, this approach will not work. But I suspect that you are in a situation where <10 names in the translation table will work and that is a small enough number that you can manage this process.