The whole formulation of the problem is the apparent
anti-pattern. Please see:
https://en.wikipedia.org/wiki/Anti-pattern#Software_engineering[
^].
One anti-pattern is well-known and can be found in the list of anti-pattern published in this article: see "The use of patterns has itself been called an anti-pattern, a sign that a system is not employing enough abstraction".
I formulate the similar methodological problem like this: "thinking that the use of some pattern is the goal of development".
Another anti-pattern is not in the list. I call it: using the architecture which requires
polling. To understand the problem, please see my past answer:
Application 'dashboard' for website accounts[
^].
Note that the problems I tried to outline in this answer cannot be solved with FTP, which is inherently oriented to pure
client-server model (
https://en.wikipedia.org/wiki/Client%E2%80%93server_model[
^]). With HTTP, it is just difficult, but there are work-around solutions, but not with FTP.
So, the bottom-line is: you don't need to look for a pattern for this approach. You can work in two directions 1) change the architecture to the one excluding polling; 2) still explore the polling from FTP, if this is unavoidable, but simply use critical thinking and your brain to design the solution in a rational ways. Which ways? it depends on your other requirements and ultimate goals, which you did not share with us.
—SA