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