fileattrib is returning the wrong (incorrect) results

5 次查看(过去 30 天)
I have a GUI that asks the user via uigetdir for the location for some output files. As a check I want to be sure the user can write to that location. Here is the code
dn = uigetdir;
if ~(isequal(dn, 0))
if (dn(end) ~= filesep)
dn(end + 1) = filesep;
end
% check for writable directory
[~,fa,~] = fileattrib(dn);
if (fa.UserWrite == 1)
set(th, 'String', dn);
btn = findobj('tag','exec');
set(btn, 'Enable','on');
else
errordlg(sprintf('Directory: %s is not writable.', dn), ...
'Read Only')
end
Here is the result of that section for a directory that I do not have write permission.
fa =
Name: '*************************************'
archive: 0
system: 0
hidden: 0
directory: 1
UserRead: 1
UserWrite: 1
UserExecute: 1
GroupRead: NaN
GroupWrite: NaN
GroupExecute: NaN
OtherRead: NaN
OtherWrite: NaN
OtherExecute: NaN
According to the documentation I have write permission. I in fact do not. If I try to write a file I get a windows error stating as much. I can confirm I don't have permission through explorer. The documentation makes me think this should work on Windows...perhaps I missed something.

采纳的回答

Walter Roberson
Walter Roberson 2015-7-17
You are not the owner of the directory. UserWrite is the write permission that the owner of the directory would have.
  3 个评论
Walter Roberson
Walter Roberson 2015-7-17
编辑:Walter Roberson 2015-7-17
The documentation is definitely in error with regards to Unix. For MS Windows, I am having difficulty finding information about how attributes interact with multiple users. I do find this KnowledgeBase article which indicates that the official Read-Only attribute has a completely different meaning for folders. Unless fileattrib() is somehow synthesizing the write information some other way, then that example is in error in the documentation. I will send Mathworks a report on this. (report sent)
=== begin KB 326549 ===
Note Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows, Windows components and accessories, and other programs. For example, you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer.
The Read-only and System attributes is only used by Windows Explorer to determine whether the folder is a special folder, such as a system folder that has its view customized by Windows (for example, My Documents, Favorites, Fonts, Downloaded Program Files), or a folder that you customized by using the Customize tab of the folder's Properties dialog box. As a result, Windows Explorer does not allow you to view or change the Read-only or System attributes of folders. When a folder has the Read-Only attribute set it causes Explorer to request the Desktop.ini of that folder to see if any special folder settings need to be set. It has been seen where if a network share that has a large amount of folders set to Read-only, it can cause Explorer to take longer then what is expected to render the contents of that share while it waits on the retrieval of the Desktop.ini files. The slower the network connectivity to the share the longer this process can take to the point where Explorer may timeout waiting for the data and render nothing or appear to hang.
Matt
Matt 2015-7-17
I found a function in the exchange that creates a directory and checks to see if the mkdir operation was successful. This solves the problem nicely. Thanks for looking into this Walter. I look forward to see what MathWorks says.

请先登录,再进行评论。

更多回答(0 个)

类别

Help CenterFile Exchange 中查找有关 File Operations 的更多信息

标签

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by