fileattrib is returning the wrong (incorrect) results

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.

Answer 1

[Walter Roberson]

You are not the owner of the directory. UserWrite is the write permission that the owner of the directory would have.

[Matt]

Walter what you say directly contradicts the documentation. Here is the text from MathWorks:

from `doc fileattrib`

View attributes of the current folder, assuming the current folder is C:\my_MATLAB_files.

fileattrib

ans = 

              Name: 'C:\my_MATLAB_files'
           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

The attributes indicate that you have read, write, and execute permissions for the current folder.

End example...

Is the documentation in error?

[Walter Roberson]

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]

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.