看来我需要在这里为所有人更新完整的场景。
我们的用户需要从我们的文件服务器中获取他们需要的任何内容以同步到远程位置，但是用户在文件服务器上移动文件的权限有限。所以这是我的任务：
创建一个用户可以用于拾取数据并同步到远程位置的工具。DFS 和第三方工具不是选项，必须是我们自己编写的代码，并且所有内容都必须在后台运行。
这是我的方法，现在正在运行。我制作了 3 个组件：
**A**** 带有 VBS 的 HTA 应用程序位于用户电脑上，为用户提供文件浏览器来获取数据。
**B**** 允许 HTA 将数据路径写入 txt 文件的共享位置。此文本文件中的任何路径都将作为软链接到最终位置。
**C**** 文件服务器上的最终位置保存所有软链接。
它的基本工作原理如下：
用户使用我制作的 HTA 从文件服务器中获取数据，它会将完整的数据路径写入共享位置上的 000.txt 文件。我的无限循环脚本监视此共享位置，如果任何用户在此共享文件夹中创建了 000.txt 文件，它将调用另一个脚本来读取此 000.txt 中的所有数据路径，并mklink根据用户提供的路径创建软链接，并将软链接输出到最终位置，然后删除 000.txt 文件。此最终位置上的所有软链接将在夜间按计划同步robocopy。我的 HTA 应用程序中还需要更多功能，无需谈论它。
因为这里没人谈论编码，所以我删除了无限循环代码，这个循环脚本从 Windows 启动并作为服务运行。我可以随时启动/停止它。它基本上只是监视那个共享文件夹，如果有任何用户在那里创建了 000.txt 文件，它将调用mklink.bat来制作软链接，并且在制作软链接时将删除 000.txt mklink.bat。我使用无限循环而不是任务调度程序的原因是用户需要在提交数据路径后立即在最终位置看到结果。我以为任务调度程序的最小间隔是一分钟，（@MikeAWood 说可以是 1 秒。谢谢！）所以我做了一个 2 秒间隔的无限循环来监视该共享文件夹。
我的问题如下：
在服务器上永远运行无限循环来监视文件夹是一个好主意吗？
脚本运行时，我监控了服务器上的资源使用情况。我没有看到任何重大消耗……所以我想这不会造成危害，对吧？
如果任务调度程序可以处理 1 秒间隔，我想我的问题已经解决了。谢谢大家。
或者如果您有更好的方法或对我的方法有任何意见。
答案1
作为此方法的一般替代方案：将脚本放入任务计划程序中，每分钟、每两分钟触发一次。这更可靠，因为您的进程可以承受重启或脚本错误。使用计划任务不仅可以让您的进程承受重启（如前所述），还可以通过组策略首选项使您的任务可以部署到大量服务器。您当前的解决方案不利于可扩展性和可靠性。
至于您正在谈论的实际脚本 - 似乎您正在重新发明 DFS-R 和/或 Robocopy 的科学怪人。
DFS-R是 Windows Server 内置的可扩展、成熟的文件复制工具。您应该看看是否可以在这种情况下使用它。微软在 DFS-R 中投入的工程智力远远超过您在执行相同操作的脚本中投入的工程智力。
此外，即使你因为某种原因无法使用 DFS-R，机器人复制有一个/mir开关，它将镜像目录。如果您出于某种原因确实无法使用 DFS-R，至少在脚本中使用类似的东西。
答案2
你应该因为询问你的方法而受到赞扬。很容易按照你的第一个想法去做，但最好与其他人一起验证。
您的方法存在几个问题：
- 每次服务器重启时都必须手动重启
- 它要求你使用具有源和目标访问权限的凭据保持登录到控制台
- 已经有工具可以做到这一点（DFS，计划任务等）
（正如您所提到的，其中一些问题可以通过该服务解决。）话虽如此，只有您才能评估您所面临的问题的任何特定解决方案的有效性。至少现在您有选择。
答案3
肯定有比无限循环更好的方法。无限循环很痛苦，会让所有人在各个层面都感到沮丧。请不要这样做。
答案4
我很好奇你为什么问这个问题。有几个人提供了替代解决方案，而他们的回答似乎是你被命令这样做。你是在寻找替代方案，还是在寻找借口回到你的经理那里抗议这样做？
其他答案已经列举了不这样做的原因：
它很容易发生故障，无法承受故障、系统重启或任何类型的处理错误。
您需要付出努力（而不是供应商的努力）来维护
这种方法存在安全风险
效率相对较低
至于替代方案，我也有过使用 DFS 的糟糕经历，并使用 DoubleTake Replication 取得了很好的效果。然而，DFS 的后续版本解决了我使用 DFS 时遇到的问题，现在我们使用它进行跨 WAN 的 DR 复制。