I don’t know if this is purely an OS bug, or if it could be amended with design changes in xrni/xrns structure, or loading of those.
Like someone saw in an earlier topic, if you make e.g. too long formulas in the Overtune tool, you can easily get a instrument/sample that will work fine as long as Renoise is running, but the saved song won’t load correctly anymore once it’s been closed. My guess is that different OSes have different ways of assigning a tmp filename and different partition types have different max filename lengths… In my example I had a song with 3 layered snares, two of them did not load back into renoise with a error along the lines of “cannot load sample (samplename>200 chars): unable to open file (dito) for writing”
I will try to upload the example song/loop I’ve made this afternoon.
Alright so to sort this out in some way or another, I want to maybe script something that could detect extremely long sample (and therefore, to be file-) names, and truncate those in Song.xml and in the zip that is the .xrns at once. Would anybody know what is an appropriate language for something like that?
Should I use Python, Ruby (because I like programming in those), plain bash script, ??
I think this should be fixed by Renoise simply applying sort of a SFN equivalent of the sample filename and store the original sample-filename into a “slot-title” field.
This would prevent any kind of mess with this system. There used to be a limit to a full pathname (including (sub)foldernames) of 255 characters on Windows. For Windows XP, this is still very true. Haven’t tested this on Windows 7 yet though.
I just had the bug on a very long sample name, on linux. So yeah. I pray for that solution 
.