While we are in here, consider renaming this variable, its not idiomatic java

Done.

TheFile.exists call is redundant here:https://docs.oracle.com/javase/6/docs/api/java/io/File.html#isDirectory()

Done.

I believe you can usecolumnFamilyDirPath.resolve(monitoringFolder) here instead of converting back and forth between string and path. Reference:https://docs.oracle.com/javase/8/docs/api/index.html?java/nio/file/Path.html

Done.

Same comment here that theFile.exists call is redundant.

Done.

I like this cleanup 🙌

Since the move is non-atomic I can see a weird edge case where we start Cassandra while the move is happening (and we have like 10,000+ files). Should we have some sort of "fence" that tells the subsystem that starts Cassandra it needs to wait while this happens?

Yes we should. I will need to address this in a follow-up, however. This is analogous to Cassandra getting started accidentally before the full download is complete the in the model we use today. Which hasn't happened yet, knock on wood. It might requires some rethinking about consolidating Cassandra's remediation policy in our environment. That is, the between Priam and systemd.

If am reading this right, if the source path we are currently iterating over is a directory we recurse by moving the files in that directory into[destination/directory name]. Cant we just move the entire directory instead of recursing then?

My goal here was for the the operation to be strictly additive. That is, if there are already files present I want to ensure that for them to get overwritten that the operator does something explicit.

Note that to that end I have changed the policy regarding whether to replace files if they are already present in a follow-up commit.

Do we need this error or just skip/log? Likely an edge case but do we really want to fail if thats the case?

In the new model using walkFileTree() we always continue.

Question about this: I know we don't need to stopcass anymore because we useimport but I was surprised to see we no longer clean the directory. Is this for the case where we want to restore a subset of the data but keep whats there? Do we still need the option to clean the directory for some restores?

The common cases for restores are:

1. Restores into empty clusters (e.g., red-black)
2. Restored into live clusters (e.g., emergencies)

In neither case do we want any data to be deleted. I would prefer that in outlier cases where that is required that there is a separate explicit job or command that the operator needs to run to best manage expectations. It is scary today that we could configure Priam such that a restart deletes all of the data.

do we want to use the list of failed imports somewhere to log what failed and be able to resume? instead of starting over from the beginning?

Also if we only need the boolean why return the list? I would rather us use the list but if we are not going to I mean.

This is a good point. In case we don't specify --copy-data and Cassandra's behavior is to remove the origin files regardless of successful import, we want a log of what failed so we can at least get a sense of the scope of what is missing. I will log the failures.