primefaces复制多个目录

这个问题是关于Web应用程序的部署。

介绍（你可以跳过）

我使用的是django，而我的托pipe服务提供商设置django支持的方式最终导致webapp至less分散在三个位置：

实际的应用程序代码在/something/<my_apps>/
/something/<my_site>/网站设置/url/模板/something/<my_site>/
CSS，JavaScript和其他“媒体”在/something_else/media/

所以当我部署/升级网站时，我需要一次更新多个目录。

实际问题：

有没有办法做一个primefaces文件复制？我不是以linux系统为“专家”的，所以请原谅我的无知。

复制操作涉及几个目录树，基本上是两个或三个：

 copy _tree1 to tree1 copy _tree2 to tree2

我的意思是：

它要么完全复制，要么根本不复制。它不应该处于某种复制的状态，而是一些失败的状态。
这是在尽可能短的时间内完成的。理想情况下，应该没有时间点系统看到副本，因为它正在进行，它要么看到旧版本的文件或新版本; 在任何时候都不应该看到旧版本的文件A，而是新版本的文件B.如果这不是完全可能的话，那么它应该不超过几毫秒。

我的想法是有双缓冲的东西：我准备在暂存区域的一切，例如， _tree_x ，然后复制将其移动到tree_x应该是一个primefaces操作，只是改变指针在磁盘上。

我认为一个这样的拷贝移动操作在linux中是primefaces的，（不是吗？），但是我需要几个这样的操作也是primefaces的。我希望他们被视为一个单一的移动操作。

我认为你在一个中转区正确的轨道上。我不知道任何primefaces命令，但是如果你打开你的文件，然后使用一个脚本删除第一个目录并移动（而不是复制）第二个目录，并为所有三个目录做，它应该是非常快的。

或者，您可能要使用符号链接。这样你可以粗略地：

 /version/22/<my-apps> /version/22/<my-site> /version/22/<my-media>

并使用相同的子目录部署/version/23目录。然后，在实际的文件将去（再次，为了速度，你需要一个脚本），你可以使用一个符号链接，当任何人去到最新的页面，他们得到任何版本是最新的（这一切发生透明，他们不知道）。这样做的好处是，你的老作品仍然存在，直到你决定删除它。 [虽然，授予版本控制系统是一个更好的事情来保持旧的工作。]

你必须检查1）你可以运行脚本（并且以这种方式Web用户不能！），2）你可以使用符号链接（因为一些Web服务器被configuration为不遵循它们）。

也许我没有完全想到这一点，但为什么不把你的复制操作到一个新的目录？当它完成“mv”旧目录到另一个名称和“mv”新目录到所需的名称。

这在技术上并不是primefaces的，因为有一段时间，旧的目录将被移动，新的目录将不会到位，但可能是足够好的。

对于大型网站，可以通过让多个服务器处理请求来处理网站更新。然后，您可以将一台服务器脱机，更新它，然后将其重新联机，并为群集中的其他服务器重复。

对于单个托pipe网站，通过在根文件夹中的index.html中放置网站closures页面，然后执行更改，closures网站也许是有意义的。

如果您确实需要尽可能多地保持网站的正常运行，我可以提出以下build议：

primefaces的副本不存在，但是，重命名单个文件夹确实是自发的。通过将这些重命名文件放到一个脚本中，并运行这个脚本，就可以让一系列的重命名一个接一个地发生。您将需要两倍的磁盘空间作为站点同时在服务器之前和之后的文件夹。
这并不能解决你的问题 – 只是减less了曝光。之前和之后的版本可能需要不同的数据库数据字段，所以SQL查询也需要运行。一个人可能会在更新发生的同时进行页面加载。网页加载的开始可以在更改之前加载页面，页面加载的最后部分可以使用复制之后的文件。

首先，最好的办法是改变你的httpdconfiguration指向新的目录，然后重启httpd。我认为这是不可能的。

我有一个想法，假设您的三个目录中的数据不会一直在改变，因为它需要这三个原始目录的非primefaces移动到这些目录的副本。我不是100％肯定这会起作用，但你可以testing它。把这个脚本写成脚本比用英语解释更容易。让我知道是否需要进一步解释。

假设三个标称path是：/ pathA / dir1，/ pathA / dir2，/ pathB / dir3

  mkdir / pathC
 ln -s pathC / linkI
 cd / pathA
 tar pcf  -  dir1 |  （cd / pathC; tar pxf  - ）
 tar pcf  -  dir2 |  （cd / pathC; tar pxf  - ）
 cd / pathB
 tar pcf  -  dir3 |  （cd / pathC; tar pxf  - ）
 cd / pathA
 mv dir1 dir1.orig && ln -s / linkI / dir1 dir1
 mv dir2 dir2.orig && ln -s / linkI / dir2 dir2
 cd / pathB
 mv dir3 dir3.orig && ln -s / linkI / dir3 dir3
 mkdir / pathD
 cd / pathD
 mkdir dir1
 mkdir dir2
 mkdir dir3
 （cd dir1 &&）
 （cd dir2 &&）
 （cd dir3 &&）
 cd /
 ln -sf pathD / linkI

（编辑：嗯，不知何故，我错过了克林顿·布莱克摩尔的回应，这与我所build议的基本相同，所以没关系。）

对于那些阅读这个老问题的人来说，这是可能的，但它需要很多符号链接。

我的答案是基于克林顿·布莱克莫尔（目前接受的答案）。

多个目录（或多个文件，就此而言）不能自动更改。所以我们不能直接使用目录。单个文件可以使用rename（）系统调用自动更新（用新文件replace旧文件）。符号链接可以用同样的方法更新，使用mv -T让mv不引用目的地。

所以，如果我们有这些目录：

 /srv/dirA/ /srv/dirB/ /srv/dirC/

我们可以使它们都成为另外三个目录的符号链接：

 /srv/dirA -> /version/current/dirA /srv/dirB -> /version/current/dirB /srv/dirC -> /version/current/dirC

/version/current ，反过来，只是一个符号链接到当前版本的目录：

 /version/current -> /version/22/

整个Web应用程序可以用两个简单的命令来更新，其中最后一个一次“replace”所有三个目录（它实际上并不替代目录，它只replace那些目录指向的目录）：

 $ ln -s /version/23/ /version/next $ mv -T /version/next /version/current

我没有实际testing过，但应该可以工作。 -T标志可能是一个非标准的标志。作为替代，可以使用python -c "import os; os.rename('/version/next', '/version/current')" （也未经testing）。

我不知道会对性能产生什么影响，但是如果你已经在运行Django，那么我怀疑它是否有意义。我认为，如果你正在服务大量的可能性最低的静态文件（比如CDNs），那么这可能很重要，即使如此，它也可能只是一个小的性能影响。总之，你不应该担心performance。

请注意，有几个问题：Django是一个服务器，不会在同一时间重新启动。因为这是真正的primefaces，所以Django必须以一种完全忽略“当前版本”的方式来build立。相反，您将从当前版本启动Django以供生产使用。为了更新，下一个版本将开始，然后服务器将重新启动（我假设大多数networking服务器有一些重新启动，而不会离线），整个过程应该是primefaces。但我不是这方面的专家。

另一个问题（如Ptolemy提到的）是，在繁忙的服务器上，会有一些人从一个版本中部分地看到页面，而另一部分则由于caching以及在页面加载期间在不同时间请求多个资源资源负载之间可能有几秒钟）。我想到了这两个，caching将是最重要的，但也是最容易解决。不过，我怀疑这实际上是一个问题。

你有没有尝试过使用atomic-rsync ？它使用其他答案中build议的rsync和mv命令的组合。