If fs.renameSync fails, try fs.copySync and fs.unlinkSync instead

[rcannood]

Issue

When setup-nextflow is ran after easimon/maximize-build-space, the fs.renameSync fails.

In github action:

      - uses: easimon/maximize-build-space@v7
      - uses: nf-core/setup-nextflow@v1.3.0

Results:

Run nf-core/setup-nextflow@v1.3.0
Input version 'latest-stable' resolved to Nextflow Version 23.04.2
Preparing to download from https://github.com/nextflow-io/nextflow/releases/download/v23.04.2/nextflow
Error: EXDEV: cross-device link not permitted, rename '/home/runner/work/_temp/f369ad38-5c5e-41aa-80b1-0ea1984b0f34' -> 'nxf-v23.04.2bkEavA/nextflow'
Warning: Nextflow appears to have installed correctly, but an error was thrown while running it.

Changes

• If fs.renameSync fails (e.g. because source and destination files are on different partitions), try fs.copySync and fs.unlinkSync instead.

[rcannood]

Hello @MillironX @emiller88 ! Would you have a chance to take a look at this?

[edmundmiller]

Hmm, I'm trying to think of things this could break...

Maybe we could hide it behind a variable?

I guess worst case, we can roll it back. I'm fine with it, but let's wait for @MillironX!

[kenibrewer]

I recently joined the nf-core org and am a new face in this repo, but I disagree with merging these changes. It adds a lot of lines of code to deal with an unexpected interaction with a not very commonly used action (maximize-build-space only has 205 stars).

Also, I think it should be on easimon/maximize-build-space to ensure that their action doesn't break common commands like fs.renameSync. There are a lot of possible actions that use fs.renameSync and instead of merging similar changes to all of them, perhaps maximize-build-space should create a fix on their end?

[rcannood]

@emiller88: Thanks for the positive feedback!

---

@kenibrewer: I guess I should have better explained what the root cause of the issue is, namely that fs.renameSync does not allow to rename files across partitions. The issue I'm trying to fix is thus not unique to this particular use case.

As a side note, what easimon/maximize-build-space does is it creates a large image stored on multiple mount points in order to maximise the amount of space that the user is able to work with.

---

It adds a lot of lines of code

I'd argue that providing a failover mechanism for errors that your users are encountering is not added complexity, but just graceful handling.

-  fs.renameSync(nf_dl_path, nf_path)
+  try {
+    fs.renameSync(nf_dl_path, nf_path)
+  } catch (err: unknown) {
+    core.debug(`Failed to rename file: ${err}`)
+    fs.copyFileSync(nf_dl_path, nf_path)
+    fs.unlinkSync(nf_dl_path)
+  }

---

not very commonly used action (maximize-build-space only has 205 stars).

Star count is not a good metric for how useful a tool is. That aside, I'm actually surprised that I'm the first to report this issue, since the maximize-build-space action is commonly used when a lot of disk space is needed.

In particular, I use it to test Nextflow pipelines which require large Docker images (e.g. the nvcr.io/nvidia/pytorch easily use up 10GB of disk space) and which require large test datasets.

As such, I'd be surprised if I'm the first one to encounter this issue. A potential workaround would be to just download Nextflow the old fashion way on github CI (i.e. curl -s https://get.nextflow.io | bash && mv nextflow /usr/bin/local/nextflow), but I thought it'd be more helpful to contribute a solution to the problem I was encountering :)

---

Also, I think it should be on easimon/maximize-build-space to ensure that their action doesn't break common commands like fs.renameSync.

I don't think this is possible. The "EXDEV: cross-device link not permitted" is an error inherent to fs.rename and fs.renameSync. See this stackoverflow for more information.

---

I hope this addresses any concerns you may have, @kenibrewer. If you feel my proposed solution could be improved upon, I'd be happy to incorporate your suggestions in my PR.

[edmundmiller]

I'd argue that providing a failover mechanism for errors that your users are encountering is not added complexity, but just graceful handling.

I agree, I was more afraid of silent errors because it was handled. 😆

Do you have an example of it in use? Sorry, I forgot to kick off the tests, let's see if they all pass!

[kenibrewer]

@rcannood Thanks for the explanation, and I apologize for being a bit too harsh on your pull request when I didn't fully understand the context behind the changes. Everything you've explained makes sense to me and your solution seems like the best course forward to me too. Cheers!