Windows 如何确定/处理任何给定文件的 DOS 短名称?
我有一个包含这些文件的文件夹:
alongfilename1.txt <--- created first
alongfilename3.txt <--- created second
当我在命令提示符中运行 DIR /x 时,我看到分配了这些短名称:
ALONGF~1.TXT alongfilename1.txt
ALONGF~2.TXT alongfilename3.txt
现在,如果我添加另一个文件:
alongfilename1.txt
alongfilename2.txt <--- created third
alongfilename3.txt
我会看到:
ALONGF~1.TXT alongfilename1.txt
ALONGF~3.TXT alongfilename2.txt
ALONGF~2.TXT alongfilename3.txt
很好。 它似乎是根据我创建文件的日期/时间分配“~#”。 它是否正确?
现在,如果我删除“alongfilename1.txt”,其他两个文件保留其短名称。
ALONGF~3.TXT alongfilename2.txt
ALONGF~2.TXT alongfilename3.txt
该 ID(在本例中为 ~1)何时会被释放以用于另一个短名称。 会永远吗?
另外,是否有可能我的计算机上的文件的短名称为 X,而同一文件在另一台计算机上的短名称为 Y? 我特别关心自定义操作使用 DOS 短名称的安装。
多谢你们。
I have a folder with these files:
alongfilename1.txt <--- created first
alongfilename3.txt <--- created second
When I run DIR /x in command prompt, I see these short names assigned:
ALONGF~1.TXT alongfilename1.txt
ALONGF~2.TXT alongfilename3.txt
Now, if I add another file:
alongfilename1.txt
alongfilename2.txt <--- created third
alongfilename3.txt
I see this:
ALONGF~1.TXT alongfilename1.txt
ALONGF~3.TXT alongfilename2.txt
ALONGF~2.TXT alongfilename3.txt
Fine. It seems to be assigning the "~#" according to the date/time that I created the file. Is this correct?
Now, if I delete "alongfilename1.txt", the other two files keep their short names.
ALONGF~3.TXT alongfilename2.txt
ALONGF~2.TXT alongfilename3.txt
When will that ID (in this case, ~1) be released for use in another shortname. Will it ever?
Also, is it possible that a file on my machine has a short name of X, whereas the same file has a short name of Y on another machine? I'm particularly concerned for installations whose custom actions utilize DOS short names.
Thanks, guys.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

发布评论
评论(5)
短文件名是随文件一起创建的。 该算法的工作原理如下(通常,但请参阅 moocha的回复):
counter = 1
stripped_filename = strip_dots(strip_non_ascii_characters(filename))
shortfn = first_6_characters(stripped_filename)
while (file_exists(shortfn + "~" + counter + "." + extension)) {
increment counter by 1
if more digits are added to counter, shorten shortfn by 1
/* e.g. if counter comes to 9 and shortf~9.txt is taken. try short~10.txt next */
}
这意味着一旦创建文件,它将保留其短名称,直到被删除。
一旦文件被删除,短名称就可以再次使用。
如果您将文件移动到其他位置,它可能会获得一个新的短名称(例如,您将 c:\somefilewithlongname.txt ("c:\somefi~1.txt") 移动到 d:\stuff\somefilewithlongname.txt,如果有 d:\stuff\somefileelse.txt ("d:\stuff\somefi~1.txt"),移动文件的短名称将为 somefi~2.txt)。 似乎短名称仅在给定计算机上的给定目录中持久存在。
因此:短文件名将由文件系统生成,通常是通过上面概述的方法。 最好假设短文件名不是持久的,因为一台计算机上的 c:\longfi~1.txt 可能是“c:\longfilename.txt”,而在另一台计算机上可能是“c:\longfish_story.txt”; 此外,当文件被删除时,短名称立即再次可用。
此链接说明了 NTFS 的作用它。 我猜想在更新的版本中仍然是相同的想法。
在 Windows 2000 中,FAT 和 NTFS 都使用
他们的 Unicode 字符集
名称中包含一些禁止的内容
MS-DOS 无法读取的字符。 到
生成一个 MS-DOS 可读的短文件
名称,Windows 2000 删除所有
这些来自 LFN 的字符和
删除任何空格。 因为一个
MS-DOS 可读的文件名可以有
只有一期,Windows 2000也
删除所有额外的句点
文件名。 接下来,Windows 2000
如有必要,截断文件名,
最多六个字符并附加一个波形符
(~) 和一个数字。 例如,每个
附加不重复的文件名
与〜1。 重复文件名结束
先是 ~2 ,然后是 ~3 ,依此类推。 后
文件名被截断,文件
扩展名被截断为三个
或更少的字符。 最后,当
在命令中显示文件名
行,Windows 2000 翻译所有
文件名中的字符和
扩展为大写。
当文件由运行 Samba 的网络服务器提供时,短名称由服务器生成,并且它们不遵循可预测的模式。
因此,假设您可以预测简称的形式是不安全的。
G:\>dir /x *.txt
Directory of G:\
08/25/2009 12:34 PM 1,848 S2XYYV~1.TXT strace_output.txt
03/01/2010 05:32 PM 325,428 TEY7IH~O.TXT tomcat-dump-march-1.txt
03/11/2010 12:01 AM 5,811 DI356A~S.TXT ddmget-output.txt
01/23/2009 01:03 PM 313,880 DLA94Q~K.TXT ddm-log-fn.txt
04/20/2010 07:42 PM 7,491 A50QZP~A.TXT april-20-2010.txt
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
如果我是您,我将绝不会依赖任何文件系统驱动程序的任何版本(无论是 Microsoft 的,还是其他操作系统的)来使其用于生成短文件名的算法保持一致。 Microsoft Fastfat 和 NTFS 驱动程序的确切行为没有“正式”记录(除了一些高级概述),因此不是 API 合同的一部分。 如果您更新驱动程序,今天有效的明天可能就无效了。
此外,绝对不要求短名称包含波浪号字符 - 例如参见 雷蒙德·陈的这篇文章。
在 MSDN 博客中可以找到有关此主题的大量信息 - 例如:
另外,不要依赖于字母数字字符的唯一存在。 看看 Linux VFAT 驱动程序 例如,大写字母、数字和以下字符的任意组合都是有效的:$ %'`-@{ }~! # ( ) & _ ^。 NTFS 将以兼容模式运行...
If I were you, I would never rely on any version of any file system driver (be it Microsoft's, be it another OS's) to be consistent about the algorithm it uses to generate short file names. The exact behavior of the Microsoft Fastfat and NTFS drivers is not "officially" documented (except as somewhat high level overviews) thus are not part of the API contract. What works today might not work tomorrow if you update the driver.
In addition, there is absolutely no requirement that short names contain tilde characters - see for example this post by Raymond Chen.
There's a treasure trove of info to be found about this topic in the MSDN blogs - for example:
Also, do not rely on the sole presence of alphanumerical characters. Look at the Linux VFAT driver which says, for example, that any combination of uppercase letters, digits, and the following characters is valid: $ % ' ` - @ { } ~ ! # ( ) & _ ^. NTFS will operate in compatibility mode with that...