看起来我需要在这里更新所有的场景。
我们的用户需要从我们的文件服务器获取所需的任何信息以同步到远程位置，但是用户在文件服务器上的权限有限，无法移动文件。 所以这是我的任务：
创build一个用户可以用来拾取数据和同步到远程位置的工具。 DFS和第三方工具不是选项，必须由我们自己编写的代码，一切都必须在后台运行。
这是我的方法，现在正在工作。 我做了3件组件：
**一个**** HTA应用程序与坐在用户PC上的VBS提供给用户一个文件浏览器来获取数据。
** B ****允许HTA将数据path写入txt文件的共享位置。 这个文本文件中的任何path将被制作为最终位置的软链接。
** C ****文件服务器上的最终位置保存所有的软链接。
这是基本的工作原理：
用户使用我制作的HTA从文件服务器中挑选数据，它会将完整的数据path写入共享位置上的000.txt文件。 我的无限循环脚本监视这个共享的位置，如果000.txt文件是由这个共享文件夹中的任何用户创build的，它将调用另一个脚本来读取000.txt中的所有数据path，并使用mklink来制作基于path的软链接用户提供并输出到最终位置的软链接，然后删除000.txt文件。 这个最终位置上的所有软链接将在夜间按照计划进行同步。 我的HTA应用程序需要更多的function，不需要谈论它。
由于没有人在这里谈论编码，所以我删除了我的无限循环代码，这个循环脚本从Windows开始，作为服务运行。 我可以随时启动/停止。 它基本上只是监视共享文件夹，如果有用户在那里创build000.txt文件，它将调用mklink.bat来制作softlins，并且在build立softlink时，000.txt将被mklink.bat删除。 我使用无限循环而不是任务调度器的原因是用户需要在提交数据path之后立即在最终位置查看结果。 我认为任务调度程序的最小间隔是1分钟，（@MikeAWood说可以是1秒，谢谢！），所以我做了一个2秒的间隔无限循环来监视共享文件夹。
我的问题如下：
这是一个好主意，永远运行在服务器上的无限循环监视文件夹？
在脚本运行时，我监视服务器上的资源使用情况。 我没有看到任何重大的消耗…所以我想这将是无害的权利？
如果任务调度程序可以处理1秒的时间间隔，那么我想我的问题就解决了。 感谢大家。
或者，如果你有更好的方法来做到这一点，或者我的方式有任何意见。
作为一个普通的select：把你的脚本放在Task Scheduler中，然后每分钟，两分钟，不pipe怎样。 这是更可靠的，因为你的过程中保持重新启动或脚本错误。 如前所述，使用计划任务不仅可以让您的进程保持重新启动，还可以通过组策略首选项将您的任务部署到大量服务器上。 您目前的解决scheme是可扩展性和可靠性的敌人。
至于你正在谈论的实际脚本 – 看起来你正在重新发明一个科学怪人的DFS-R怪兽和/或Robocopy。
DFS-R是一个内置于Windows Server中的可扩展的，成熟的文件复制工具。 你应该看看你是否可以在这种情况下使用它。 微软已经把更多的工程大脑力量投入到DFS-R中，而不是把它放在一个脚本中去做同样的事情。
而且，即使由于某些原因您不能使用DFS-R， robocopy也会有一个/mir开关，它将镜像目录。 如果由于某种原因你真的不能使用DFS-R，至less在脚本中使用这样的东西。
询问你的方法应该受到赞扬。 它很容易与你有第一个想法运行，但更好与其他人一起validation。
你的方法有几个问题：
（这些问题中的一部分可以像你提到的服务那样解决。）也就是说，只有你可以评估任何特定解决scheme对你面临的问题的有效性。 至less现在你有select。
确实有更好的办法，比运行无止境的循环。 无尽的循环是痛苦的，并导致所有人对所有人都感到挫折。 请不要这样做。
我很好奇你为什么问。 有几个人提出了替代解决scheme，似乎是你被命令这样做。 你正在寻找替代品，或者你正在寻找弹药回到你的经理和抗议这样做？
其他答案列举了不这样做的原因：
它很容易失败，因为在失败，系统重启或任何types的处理错误中不能存活。
它需要您的努力（而不是供应商）维护
这种方法存在安全风险
这是相对低效的
就替代品而言，我也对DFS有过不好的经验，并且使用了DoubleTake复制function，效果很好。 然而，随后的DFS版本解决了我在DFS方面的问题，现在我们将其用于跨WAN的DR复制。