【问题标题】:File does not show on explorer, but VB.NET open it文件未显示在资源管理器中,但 VB.NET 打开它
【发布时间】:2012-08-08 14:15:38
【问题描述】:

我的程序在windows系统路径下写入一些文件(C:\windows\syswow64...)。

其中一个文件因测试原因被删除,我们正在更改某些内容,需要将其删除。好的,这里没有问题,文件不见了(几乎......)。 问题是,我的应用程序仍在获取文件!很好玩,因为我真的删除了文件(shift+del)

我用 FileInfo 类测试文件是否存在。

我要疯了。我看不出哪里错了。 当然,在文件夹选项中启用以查看隐藏和系统文件...

谢谢

我的代码如下:

Public Shared Function GetUserConfigFile() As String
    Dim UserConfigFile As String = Metodos.GetUserConfigPath("config.gf")
    'Above we have C:\Windows\SysWOW64\Microsoft\....\config.gf

    Dim ConfigFile As New IO.FileInfo(UserConfigFile)
    ConfigFile.Refresh()

    EventLog.RegisterDebugMessage("ConfigFile.Exists:{0};ConfigFile.Length:{1}", ConfigFile.Exists, ConfigFile.Length)
    If ((ConfigFile.Exists AndAlso ConfigFile.Length = 0) OrElse Not ConfigFile.Exists) Then
        Dim config As StreamWriter = IO.File.CreateText(UserConfigFile)
        config.WriteLine("<?xml version=""1.0""?><cnfg></cnfg> ")
        config.Close()
        config.Dispose()
    End If
    EventLog.RegisterDebugMessage("config.gf -> {0}", IO.File.ReadAllText(UserConfigFile))
    '''''''''''And here it's show me the content of the file... -.-''''''

    Return UserConfigFile
End Function

【问题讨论】:

  • 你确定你在同一条路径上工作吗?
  • 你现在真的不应该在任何系统目录中写入文件。
  • 是的...我之前考虑过这个...因为我们可以将此文件放在 SysWOW64 或 System32 上...我都尝试了,但没有成功。我需要在那里写我的文件。
  • 您是否尝试过在调试器中检查UserConfigFile 是否包含您期望的路径?此外,用户配置文件通常不会进入系统目录。
  • 是的。与我正在寻找的路径相同。我知道这不是最好的地方,但我需要它。我无法改变它。我只是试图将文件复制到指定的路径,你想知道吗?它是。我很确定这是小问题,但我看不到。

标签: c# vb.net explorer fileinfo hidden-files


【解决方案1】:

与 Mark Peters 所说的非常相似,可能发生的另一件事是 UAC Data Redirection,因为您没有对该文件夹的写入权限,所以您真正看到的是位于 %LOCALAPPDATA%\VirtualStore\Windows\System32 中的文件。您的应用程序是否以管理权限运行,如果没有,文件是否会丢失?

我在Super User 上有一篇更长的帖子描述了类似的问题。

顺便说一句,为什么您“需要”让您的程序访问 windows 目录中的文件?您正在做什么将要求添加到您的程序中?

【讨论】:

  • 到底发生了什么!谢谢!你杀鬼!大声笑我们正在开发的应用程序需要对用户隐藏。你想认为那是一种病毒或类似的东西,每个人都这么认为。但事实并非如此。它是一个收集一些信息以帮助管理员管理无法停止该工具的员工的工具。
  • 您应该将其作为系统服务运行并使用组策略来防止用户禁用该服务。
  • 是的,我知道我们的做法并不是最好的。我们要将其更改为服务或驱动程序......但现在我们需要解决问题。再次感谢您。
  • +1 好答案。这就解释了差异。我喜欢 SO,因为我每天都能学到新东西。
【解决方案2】:

我猜你被文件系统重定向器 (MSDN) 击中

在大多数情况下,每当 32 位应用程序尝试访问 %windir%\System32 时,访问都会重定向到 %windir%\SysWOW64。对 %windir%\lastgood\system32 的访问被重定向到 %windir%\lastgood\SysWOW64。对 %windir%\regedit.exe 的访问被重定向到 %windir%\SysWOW64\regedit.exe。

System32 和 SYSWOW64 文件夹有一些神奇之处。 (讽刺的是,32位文件存储在WOW64中,64位文件存储在System32中)

MSDN 页面提出了一个可行的解决方案:

32 位应用程序可以通过将 %windir%\Sysnative 替换为 %windir%\System32 来访问本机系统目录。 WOW64 将 Sysnative 识别为用于指示文件系统不应重定向访问的特殊别名。这种机制灵活且易于使用,因此,建议使用绕过文件系统重定向的机制。请注意,64 位应用程序不能使用 Sysnative 别名,因为它是虚拟目录而不是真实目录。

【讨论】:

  • 有趣...但我认为不是我的情况,我直接访问 SYSWOW64 文件夹。我说的对吗?
  • 肯定如果重定向在起作用,那么读取和写入都将被重定向到同一个位置,从而否定报告的错误?
  • @Matt 你会这么认为,但对我来说确实是重定向问题
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-11-22
相关资源
最近更新 更多