Hi everyone, I may be misunderstanding something, but I encountered an

OSError: [Errno 36] File name too long

while running

nf-core/proteinfamilies

on a large HRGM2 protein database. It occurs in

REMOVE_REDUNDANCY > MERGE_FAMILIES > MERGE_SEEDS

, where a component of ~80 similar families appears to be represented by a very long output filename. Is this a known limitation, and is there a recommended workaround besides

--skip_family_merging

? I can share the full log and

.command.sh

if helpful. If this is useful context, I wondered whether a short deterministic merged-family ID plus a mapping back to the member families might avoid the filename limit.

Hi Yixuan! Nope, haven't seen this before. Do you mind opening an issue in the GitHub repo describing this bug? If you could share the input file from the specific work folder with me to test, so I can update the module and script accordingly, that would be awesome

Thanks! I’ll open an issue and share the relevant failed-workdir input files with you.

Fix on the way! I'll assign you as a reviewer so you can have a look, and when it's merged, you can test the

dev

version of the pipeline and let me know if it fixed the problem (and didn't introduce downstream ones). Hopefully it should be fine!

Thank you very much!

There you go: https://github.com/nf-core/proteinfamilies/pull/177

Hey @Evangelos Karatzas, thank you for your fast respond! I'm running the job now and will let you know once it's done😄

Alright! Just make sure you are testing the

fix

branch (not

dev)

Hey @Evangelos Karatzas, the file name issue seems resolved, but some of the cached files cannot be resumed for the later steps. So, I just re-run the whole program. I'll update you once that's finished. It might take a while :D

Hmm, weird..it shouldn't be breaking downstream steps, except for the ones that were failing >250chars, and maybe a few more very long ones >200 characters, that used to pass, but were unreadable anyway, so now are getting compacted

I just found my previous error log. I'll put that in the PR comment