Windows下删除过长路径下文件(夹)的办法

有时候在Windows下删除文件或文件夹会碰到如下错误：

The source file name(s) are larger than is supported by the file system. Try moving to a location which has a shorter path name, or try renaming to shorter name(s) before attempting this operation.

或

文件名对目标文件夹可能过长。您可以缩短文件名并重试，或者尝试路径较短的位置。

解决的办法是在命令行输入：

robocopy /MIR c:\a d:\xxx

其中c:\a是c盘新建的一个空目录，d:\xxx是路径过长的文件(夹)的根目录。执行后，你会发现d:\xxx目录已经被清空了。

使用AWS CodeDeploy的几点注意事项

AWS CodeDeploy是亚马逊云计算提供的服务之一，用来将代码更容易地部署到EC2实例或私有云实例中。

它能够根据用户配置，从S3或Github上获取最新代码，并按照用户提供的appspec.yml配置文件，在不同的hook事件阶段执行不同的脚本文件，从而使代码部署过程自动化。

比如你可将多个EC2实例分为Dev，QA，PRD三组，通过结合CodeDeploy和其他CI工具(如Jenkins），自动化完成持续交付（部署到Dev/QA实例上），持续部署（部署到PRD实例上）的任务。

在使用CodeDeploy的过程中，有以下几点事项需要注意：

• 所有EC2实例上必须安装CodeDeploy Agent服务，EC2实例之所以会响应CodeDeploy服务，都是由CodeDeploy Agent来完成工作的。
• 默认CodeDeploy Agent是通过root用户安装的，所以appspec.yml中执行脚本时，默认是以root用户身份执行。而我们的代码中用到了PM2，执行PM2命令（如pm2 start）时，需要在appspec.yml中指定以ec2-user用户执行脚本，否则相关命令执行时，会导致EC2实例cpu持续占用100%，最终导致超时而部署失败。
• sudo: sorry, you must have a tty to run sudo问题。在sh脚本中，如有需要sudo执行的命令，则需在所有EC2实例的/etc/sudoers文件中，注释掉“Default requiretty”一行。
• /bin/bash^M: bad interpreter: No such file or directory问题。这是因为在windows操作系统上修改了.sh文件，导致文件末行编码不同，而在linux机器上无法执行。解决办法是在linux机器上重新保存该文件，或在windows上用sublime打开该文件，View->Line Endings->选择Unix，保存即可。

Amazon EC2上通过NFS共享目录的注意事项

背景：拟在Amazon EC2上部署nodejs应用集群。假设nodejs部署在A和B两台机器上，通过前端的ELB（Elastic Load Balancer）分发请求到A和B机器上，两台机器分别对请求做无状态响应，这样就要求A和B机器存取完全相同的数据。由于nodejs应用需要读写本地硬盘目录（对响应速度要求高，无法采用S3存储），而Amazon目前提供的存储方案中，只有EBS（Elastic Block Storage）存储可以挂载到具体机器上以提供本地路径，所以只能选取EBS作为应用集群的存储位置。但EBS类似SAN，只能挂载到一个EC2实例机器中，如果直接挂到A或B上的话，另一台机器就无法读取其中数据。所以采用的方案是启动第三个EC2实例机器C，将EBS挂载到C机器上后，该机作为NFS服务器共享EBS的挂载目录，A和B机器作为NFS客户端，分别加载共享出来的EBS路径到各自对应目录，从而保证nodejs集群能够实时读写相同的数据。如下图所示：

问题：在C机器上挂在EBS存储卷后，修改/etc/exports文件设置了NFS共享，并且有rw, no_root_squash选项。但在A机器和B机器上通过修改/etc/fstab文件并mount -a后，发现能够加载C机器上的EBS存储到指定目录，但写入文件时提示无权限。

解决办法：确保C机器（NFS服务器）上，EBS挂载路径的所有者，与A和B机器（NFS客户端）上准备写入数据的用户要拥有相同的UID和GID。具体来说，这三台机器都是从Amazon Linux的AMI启动的，所以默认用户都是ec2-user（非root用户）。C机器上EBS挂载点是/data，一开始该目录的所有者和组均为root（因为在根目录下建立目录需要root权限），所以导致在A和B机器上加载该共享目录后，加载目录的所有者和组也均为root用户。这样A和B机器上运行nodejs的ec2-user用户就无法写入数据了。解决的具体办法是在C机器上运行”sudo chmod –R ec2-suer:ec2-user /data”命令后，在A，B机器上重新加载NFS共享目录即可。

参考：How to properly set permissions for NFS folder? Permission denied on mounting end.

目前Amazon EC2上推出了公测版的EFS（Elastic File System）存储，类似NAS，在可以提供本地存储路径的前提下，还可以挂载到多台EC2实例上。但目前只有US West(Oregon)一个区域可用。在EFS全面推出前，采用上述方案，可保证应用集群横向扩展的情况下，依然能存取相同的数据。缺点是C机器是单故障点；但数据存储在单独的EBS上，至少保证数据的生命周期不依赖具体的EC2实例机器。

北京联通，DigitalOcean和Shadowsocks

最近家里宽带换成了北京联通20M，相比之前的宽带通，质量确实高了不少，国外网站和公司vpn的速度明显快了很多。但比较奇怪的是自己搭在DigitalOcean上的Shadowsocks速度没有太大提升，有时反而还不如以前。

首先公司网络里测试Shadowsocks的时候速度比较理想，也非常稳定，说明不是DigitalOcean的问题；自己家里上国外网站速度明显快了不少，而且只要能访问的网站速度都比较快，说明北京联通也没有问题。那问题只可能是北京联通与DigitalOcean之间水土不服了。

之前自己的vps一直放在DigitalOcean的旧金山机房，因为国内这个机房的口碑普遍比较好。但在家里打开newnaw.com和自己博客的时候也能感觉到速度不如以前了，难道是联通到这个机房度的问题？ping了一下DigitalOcean在旧金山的测速页面：

11%丢包率，平均响应也都在310ms以上……感觉联通到旧金山机房确实有问题，看看其他的机房吧。DigitalOcean去年在亚洲开通了新加坡机房，但之前就看到过，据说到国内的速度不稳定，还不如其他机房。抱着试试看的心态，也ping了一下新加坡的测速页面：

平均响应时间172ms，快了几乎一倍。立刻去新建了一个vps，机房选择新加坡，之后上面部署了Shadowsocks测试了一下速度，youtube的4k视频都可以流畅观看了，有点小感动…

测试后发现Shadowsocks的速度比较稳定，于是就在DigitalOcean上创建snapshot，转移之到新加坡机房，重建vps…整个操作很简单，DigitalOcean便利性还是很好的。

后来又用traceroute试了一下新加坡机房的测试页面，发现并不像网上所说，会先绕去北美一圈，然后才到新加坡，而是直接从日本到了新加坡：

那单从传输距离来说，新加坡明显还是比旧金山近很多，也就解释了为什么新加坡机房速度会比较快了。

Shadowsocks是国内的clowwindy写的工具，在goagent沦陷，ssh速度偏慢的情况下确实给大家带来了非常大的便利。前两天中文维基百科也不能愉快地从国内访问了，借网络上一张图看看，世界前30的网站我们还能上几个……希望这已经是最坏的时候了。