vista 64 上用户桌面的 QFileInfo 权限不正确

发布于 2024-07-26 01:44:28 字数 471 浏览 8 评论 0原文

我使用以下代码来确定是否可以使用 QFileInfo 写入特定目录:

QFileInfo dinfo(dirname);
if (dinfo.exists())
  valid = dinfo.isWritable()

不幸的是,当我传入 Vista 64 上当前用户桌面的路径时:

C:\Users\USERNAME\Desktop

QFileInfo::isWritable() 返回 false。 但是,如果我将其传递给另一个目录(例如 C:\Temp),它将返回 true。 我从 QFileInfo 对象请求了目录权限,该权限为 5555(任何人都不可写)。 此代码在包括 Windows XP 在内的其他平台上按预期工作。 任何人都对这里可能发生的事情有任何想法。

作为参考,如果我删除该检查,我实际上可以将文件保存到该位置,而不会出现问题。

I am using the following code to determine if I can write to a specific directory using QFileInfo:

QFileInfo dinfo(dirname);
if (dinfo.exists())
  valid = dinfo.isWritable()

Unfortunately, when I pass in the path of the current user's desktop on Vista 64:

C:\Users\USERNAME\Desktop

QFileInfo::isWritable() returns false. However, if I pass it another directory (say C:\Temp) it returns true. I requested the directory permissions from the QFileInfo object which were 5555 (not writable by anyone). This code works as expected on other platforms including Windows XP. Anybody have any ideas as to what might be going on here.

As a point of reference, if I remove the check I can actually save the file to that location without a problem.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

不回头走下去 2024-08-02 01:44:28

因此,在对 Qt 的任务跟踪器进行了一些挖掘之后,我发现 QFileInfo::isWritable() 只对文件有效,对目录无效。 通过更改代码来询问是否可以创建感兴趣的文件而不是询问目录是否可写,我能够实现预期的结果:

QDir dir(dirname);
if (dir.exists())
{
  QFileInfo finfo(dir.absoluteFilePath(fname));
  valid = finfo.isWritable();
} 

谢谢。

So, after a bit of digging through the Task Tracker at Qt, I discovered that QFileInfo::isWritable() is only valid for use on files and not directories. By changing the code to ask if I could create the file of interest instead of asking if the directory is writable, I was able to achieve the desired outcome:

QDir dir(dirname);
if (dir.exists())
{
  QFileInfo finfo(dir.absoluteFilePath(fname));
  valid = finfo.isWritable();
} 

Thanks.

雨落□心尘 2024-08-02 01:44:28

我在这里做了一个非常疯狂的猜测,但是您检查过它是否是链接、快捷方式、别名或其他伪文件夹吗? 在我看来,您可能获得的是不可写的硬编码符号链接的权限,而不是它所指向的项目的权限。

来自 isSymLink() 文档(粗体是我添加的):

在 Unix(包括 Mac OS X)上,打开符号链接可以有效地打开链接的目标。 在 Windows 上,它会自行打开 .lnk 文件。

因此,我会检查 isSymLink() 的结果,并在必要时从 symLinkTarget() 获取真实目标 (请参阅最后一个文档;目标可能实际存在,也可能不存在)。

I'm making a very wild guess here, but have you checked to see if it is a link, shortcut, alias, or other psuedo-folder? It seems possible to me that you are getting the permissions of a hard-coded symlink, which isn't writable, instead of the permissions of the item it is pointing to.

From the isSymLink() documentation (bold added by me):

On Unix (including Mac OS X), opening a symlink effectively opens the link's target. On Windows, it opens the .lnk file itself.

So I would check the results of isSymLink(), and if necessary get the real target from symLinkTarget() (and see the documentation for the last; the target may or may not actually exist).

蓝眸 2024-08-02 01:44:28

默认情况下,目录“C:\Users\USERNAME\Desktop”在 Windows Vista 上是只读的。 这并不意味着您无法将文件写入该文件夹。 这意味着您无法调整目录本身(名称更改等)。

The directory "C:\Users\USERNAME\Desktop" is by default Read Only on Windows Vista. This doesn't mean that you can't write files to the folder. This mean that you can not adjust the directory itself (name change ect.).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文