将命令作为变量传递时，xp_cmdshell dir 的结果不同答案

【问题标题】：xp_cmdshell dir different results when passing command as variable将命令作为变量传递时，xp_cmdshell dir 的结果不同
【发布时间】：2014-06-12 21:31:29
【问题描述】：

我正在使用 SQL Server 2008 R2 创建一个存储过程来跟踪某些服务器文件夹的已用空间。对于特定目录，我遇到了一个有趣的问题。

当我运行 EXEC master.dbo.xp_cmdshell 'dir "\\servername\e$\media\Google" /s /-C' 时，我得到一个结果：

但是，当我为 dos 命令使用变量时
DECLARE @dir VARCHAR(255) = 'dir "\\servername\e$\media\Google" /s /-C' EXEC master.dbo.xp_cmdshell @dir

我得到了不同的结果：

可以看到文件数相同，但使用的字节数不同。以下是包含文件的子目录的详细信息：

不使用变量：

使用@dir 变量：

您可以看到，虽然看起来每个文件的大小相同，但总大小却不同。

我还有其他带有 zip 文件的子目录没有出现这种行为。有没有人对可能导致这种情况的原因有任何想法？或者如何解决？

【问题讨论】：

我不知道为什么会发生这种情况，但我确实在 SQL Server 2008 R2 和 SQL Server 2012 上重现了差异。（奇怪的是，我只在“Dir(s).. .bytes free”行而不是“File(s)...bytes”行。）我尝试了除 DIR 之外的一些命令，但在使用字符串和变量执行时找不到任何产生不同结果的命令。跨度>

标签： sql-server sql-server-2008-r2 dos dir xp-cmdshell

【解决方案1】：

如果人们在共享上添加、编辑或删除文件，可用字节数总是不同的。

我尝试在我的测试机器上运行它，两次执行的结果相同。我正在使用带有 2014 CTP 的 Windows 7。

您确定不存在更改总数的隐藏文件或系统文件吗？目录、索引等也占用空间但不显示。您没有为文件匹配指定通配符模式。

这是关于该主题的外行文章。

http://ask-leo.com/why_does_the_space_used_by_files_on_my_hard_drive_show_different_numbers_depending_on_how_i_look.html

如果您从 Windows 资源管理器中手动选择文件，您会得到相同的总数吗？

尝试仅指定“dir *.zip /s”。这只会选择 zip 文件。请写回结果！

【讨论】：

这个问题绝对不是因为人们处理目录中的文件——我能够始终如一地得到相同的结果。我还包括了获取隐藏文件和系统文件的选项。上面的屏幕截图中未将变量用于 dir 命令的屏幕截图与 Windows 资源管理器中显示的内容相匹配。我会看看你提出的另外两个项目。
您是否尝试使用“*.zip”运行命令来查看这些文件。那应该扔掉剩下的垃圾。
我没有机会，但我今天会 - 但是，您可以看到该子目录中的所有文件都是 zip 文件，所以我认为结果将是相同的。
很有趣，所以当我只使用 *.zip 运行时，两个结果相互匹配。我注意到不匹配结果与匹配结果的唯一区别是那些不匹配的条目中包含条目（例如上面屏幕截图中的第 25 行）。
这就是我告诉你的，也是你问题的答案。隐藏的索引、文件、目录可能会在运行之间发生变化。您正在使用 'dir \\server\directory /s' 命令来完成所有操作。如果您执行 'dir \\server\directory*.zip /s'，它只会拾取带有 zip 扩展名的文件。因此，这是操作系统的隐藏功能或副作用。 SQL Server 工作正常。 -J

【解决方案2】：

也许这不是您正在寻找的答案，但我希望它对您有所帮助:)

我在第一个比较中注意到：

181661290 - 181644906 = 16384 / 2048 = 8

所以我想也许，由于某种原因，当您使用变量时，命令会计算子文件夹的“集群大小”（我猜是 2048 字节）...

但后来我注意到：

8131596 - 8119308 = 12288 / 2048 = 6

所以只有 6 个文件夹在其中添加了 2048 个字节，我不知道为什么。

然后你说：

有趣，所以当我只使用 *.zip 运行时，两个结果相互匹配。

也许在命令行中添加开关 /a-d（不显示文件夹）可以解决问题。

我正在添加this post of sqlservercentral 我发现可能与问题有关：

CompressedBit AS CASE WHEN Attributes&2048=2048 THEN 1 ELSE 0 END,

【讨论】：

所以当我添加 /a-d 开关时，结果是一致的，但是使用的字节匹配大小，而不是磁盘上的大小。这对于我的空间跟踪应该足够好，但我仍然想知道是什么导致添加该开关修复它的问题？？？
对我来说很难弄清楚。首先我需要知道为什么只有第二对图片中显示的6个文件夹添加了2048...然后我们应该知道2048是存储在文件夹本身中的某种数据还是xp_cmdshell命令从中获取的某些数据别的地方。如果我设法配置一个环境来测试它，我会尝试。