-
Hello NextFlow Community, I am attempting to integrate a python script into my NF pipeline. In order for the python script to run, it must be passed a path to a .csv file that is stored in some location. When I run the pipeline for the first time, I see that it creates an 'Alias' to that path (running on a mac) and the script runs successfully. However, if I then try to run it again, it fails with an error saying:
This also happens on a linux server. I ran it once, worked fine. But if I run a second time, that symlink is there, and NF gets cranky that the symlink it was going to create is already there. Also, of interest, the path that I am passing is '/path/to/identity' - but NF removes the leading But mainly, interested in how I can fix the former issue. I can solve it currently by deleting the Alias and re-running, but that is not a sustainable solution in production. Thanks, |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 3 replies
-
Okay, this was solved by not including the path as an input parameter. For those that might encounter a similar problem. In other words, i had this:
Changed to this:
This results in a symlink not being created at all. So...problem avoided! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
@mribeirodantas how can I achieve the effect of Thanks! |
Beta Was this translation helpful? Give feedback.
-
I have a workaround fow now, which is to look for cached folders where the exitcode is not 0 (i.e. failed executions) and remove them, which allows me to clean up while keeping successful previous executions that
|
Beta Was this translation helpful? Give feedback.
-
Just experienced this 'Failed to create symbolic link... File exists" error as well with nextflow and python script.
To this:
|
Beta Was this translation helpful? Give feedback.
Okay, this was solved by not including the path as an input parameter. For those that might encounter a similar problem.
In other words, i had this:
Changed to this:
This results in a symlink not being created at all. So...problem avoided!