我查阅了一些基础资料:
windows下的八三命名规则(在cmd下的dir /h中的/X里提到了这个命名): http://support.microsoft.com/kb/142982/zh-cn
在Windows中禁用8.3格式的文件名 http://leonax.net/p/2775/disable-8-dot-3-name-in-windows/
Wikipedia: http://en.wikipedia.org/wiki/8.3_filename
有个疑问一直没有找到正面的回答,比如有多个文件夹的名称相同的话,~后的序号是如何定的。
经过大胆尝试,可以断定,是按照创建时间来定的。
特性如下: 在未开启这个命名的磁盘下,长文件(夹)不会拥有short name;
在开启8.3命名法的磁盘下,已创建的文件(夹)不会拥有short name;
拥有了 short name的文件(夹),在修改名称后,short name 保持不便。
自此,我想对8.3命名法的解读才算是完整。
——– 后记,最近在配置android的应用开发环境。发现jdk、sdk的环境变量出现了问题,一番倒腾后,才启动sdk manager。
心有余悸,决定进行一次彻底的袭击。
把以下内容摸了个底儿:
sdk/tool/android.bat //这个东西理论上是可以直接打卡sdk manager,如果起不来,可以在cmd里执行,查回显,以诊断问题,甚至把 bat头的“@echo off”去掉,来看看具体执行到哪一步出现了异常,十有八九是环境变量的原因
sdk/tool/lib/find_java.bat //这个是为android.bat找环境变量用的,其中还调用了下边的这个文件 sdk/tool/lib/find_java.exe //这个在命令行里可以带-h查看所支持的参数。
下边要点题,说一下为嘛这个跟8.3命名法有瓜葛: 读读find_java.bat里的内容,发现他在for in find_java.exe的回显内容时会按空格断开(我觉得这算是个官方bug, https://code.google.com/p/android/issues/detail?id=58214 )。
空格是配置jdk环境变量java_home时含有的,我对short name有过接触(但不如这次彻底),就断然把java_home用short name写了,为了避免空格嘛。 所以导致一直读不到需要的java.exe所在的位置。 根结就在与此吧。 仅供参考。
一些有价值的参考资料: http://stackoverflow.com/questions/5199811/android-sdk-manager-wont-open https://code.google.com/p/android/issues/detail?id=28196#c38
— 后后记: sdk manager是启动了,可是。。。又有了新的问题:“XXX are locking the following directory”,处处是坑啊。 坑只有踩过才能跳过吗??
——2013年11月5日
![](https://img2024.cnblogs.com/blog/35695/202408/35695-20240826070647288-243310440.jpg)