我有一个带有SP2的Windows 2003 Standard x64服务器。 从文件夹中删除大量文件夹后，如果尝试读取或操作文件夹，操作系统报告“访问被拒绝”。 检查文件夹的属性时，安全选项卡丢失，只列出常规和自定义。 我们已经尝试了一些东西。 重命名文件夹，访问被拒绝。 删除文件夹，访问被拒绝。 获取父文件夹的所有权，并将权限传播给子级，访问被拒绝。 Subinacl，访问被拒绝。 Take（cmdline），访问被拒绝。 我们正在以只读模式运行chkdsk，但尚未完成。 如果可能的话，我们希望解决这个问题，而无需重新启动或运行一个完整的chkdsk离线服务器。 有谁知道这个问题的解决scheme？
当磁盘上的SMART检查报告坏扇区时，能够识别具有坏扇区的文件并将其从备份中恢复很重要。 下面，我展示了我是如何为我的Linux / ext3 VMWARE服务器做到这一点的 – 但是有谁知道这是否可以在Windows / NTFS上完成？ 下面是我为Linux / ext3所做的工作：我首先要求驱动器进行硬件表面扫描（操作系统级以下，带有驱动器SMART电路）： vserver:~# smartctl -t long /dev/sdc 我看了一下结果： vserver:~# smartctl -a /dev/sdc … 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always – 1 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always – 9 … Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: […]
我们有一个用户运行一个robocopy命令来复制一些文件，但不幸的是，用户意外地弄乱了语法。 就像是： robocopy "\\server1\share\Accounting" \\server1\share\NewAccounting" /E /X /COPYALL /TEE 没有在目的地目录适当的报价结束了拧rocobopy目的地，如下所示： Started : Tue May 05 12:30:00 2015 Source : \\server1\share\Accounting Dest : \\server1\share\NewAccounting \E \X \COPYALL \TEE\ Files : *.* 这最终创build新的文件夹“E”，“X”，“COPYALL”，“TEE”都没有NTFS安全。 文件夹安全选项卡显示“所请求的安全信息不可用或无法显示”。 并且无法通过Windows资源pipe理器或常规命令行删除文件夹。 有问题的服务器恰好是EMC Celerra CIFS服务器。 任何想法如何清理和删除无效的新目的地？
在我的系统分区上，我有一个无法删除的文件夹。 此文件夹是通过从Acronis TrueImage备份还原文件创build的。 错误消息说： 错误0x80070570：文件或目录已损坏且无法读取。 我已经尝试启动多次运行chkdsk /r /f ，但问题仍然存在。 有没有其他的工具或CHKDSK选项，我可以尝试解决这个问题？
几个星期前，我通过NTFS上的维基百科条目阅读，并注意到有可能使用符号链接之间的许多其他function ，在Windows资源pipe理器中不明显。 还有哪些其他有用的function可能无法在维基百科中logging ，以及如何获得这些function？ 是否有用于操纵/创build/使用这些function的第三方程序，registry设置，隐藏configuration窗口，cli等？ 更新：把它变成一个社区维基。
任何处理文件服务器权限的人都知道，NTFS有一个有趣的devise特性/缺陷，称为移动/复制问题。 正如本MS KB文章所述 ，如果移动文件夹并且源和目标位于同一个NTFS卷上，则文件夹或文件的权限不会自动从父项inheritance。 如果复制文件夹或源和目标位于不同的卷上，权限将被inheritance。 这里是一个简单的例子： 在同一个NTFS卷上有两个名为“技术人员”和“经理”的共享文件夹。 技术人员组可以通过RW访问技术人员文件夹，pipe理员组可以通过RW访问“pipe理人员”文件夹。 如果某人有权访问这两个文件夹，并将子文件夹从“pipe理员”文件夹移动到“技术人员”文件夹，则移动的文件夹仍然只能由“pipe理员”组中的用户访问。 “技术人员”组即使位于“技术人员”文件夹下，也不能访问该子文件夹，并且应该从顶层inheritance权限。 正如你可以想象的，这会导致支持电话，票证和浪费周期解决这些最终用户问题，更不用说老鼠的权限巢，如果用户经常移动文件夹之间不同的安全文件夹/区域相同的音量。 问题是： 什么是解决这个NTFSdevise缺陷的最佳方法，以及如何在您的环境中处理它？ 我知道链接的知识库文章谈到了一些registry键来改变Windows资源pipe理器的默认行为，但他们是客户端，并要求用户有能力更改权限，我认为在大多数环境中是一个非启动器，如果你想要保持对文件服务器权限的控制权（以及系统pipe理员的理智）。
最近我在一个本地用户组会议上，发言人指出NTFS IO堆栈的最大吞吐量是1 GBps。 他通过同时从相同的逻辑卷将两个大文件复制到不同的逻辑卷（即[a]是源，[b]是目的地1，[c]是目的地2），并且注意到传输速率在500左右徘徊） MBps的。 他重复了这个testing几次，并指出底层存储子系统是闪存（以确保我们不怀疑存储缓慢）。 我一直在试图validation这个断言，但找不到任何logging。 我怀疑我在search错误的search条件（“1GBps NTFS吞吐量”，“NTFS吞吐量最大”）。 我感兴趣的是IO堆栈是否实际上限制在1GBps的吞吐量。 编辑 澄清：我不相信主持人意图暗示NTFS是有意限制的（如果我也暗示这一点，我很抱歉）。 我想这意味着它是文件系统devise的一个function。
每隔一段时间，我都会碰到一个我需要拥有的文件。 我通常使用cacls来更改NTFS权限，但似乎没有所有权。 在* nix下，我会运行像chown me:me <file> 。 有没有窗口相当于chown ？
我有一个项目，将生成大量的图像。 大约100万开始。 他们不是大的图像，所以我会把它们全部存储在一台机器上。 你如何build议有效地存储这些图像？ （目前的NTFS文件系统） 我正在考虑一个命名scheme…开始所有的图像将有一个从1增量名称，我希望这将帮助我稍后sorting，如果需要，并把它们放在不同的文件夹中。 什么是更好的命名scheme： a / b / c / 0 … z / z / z / 999 要么 a / b / c / 000 … z / z / z / 999 任何想法呢？