Re: mkdir() problem on windows

myuserid7:

Windows permissions can be peculiar^[1], so it could be a problem with your security settings and such. This could easily be the case if you're in a locked down environment. Try the cacls command to review your security settings on the file, like this:

C:\Users\Roboticus>cacls Music
C:\Users\Roboticus\Music Roboticus-PC\Roboticus:(OI)(CI)(ID)F
                         NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F
                         BUILTIN\Administrators:(OI)(CI)(ID)F
[download]

And you can get a help screen by invoking cacls with no arguments, which will describe the output as well:

C:\Users\Roboticus>cacls

 NOTE: Cacls is now deprecated, please use Icacls.

 Displays or modifies access control lists (ACLs) of files

 CACLS filename [/T] [/M] [/L] [/S[:SDDL]] [/E] [/C] [/G user:perm]
                [/R user [...]] [/P user:perm [...]] [/D user [...]]
    filename      Displays ACLs.
    /T            Changes ACLs of specified files in
                  the current directory and all subdirectories.
    /L            Work on the Symbolic Link itself versus the target
    /M            Changes ACLs of volumes mounted to a directory
    /S            Displays the SDDL string for the DACL.
    /S:SDDL       Replaces the ACLs with those specified in the SDDL s
+tring
                  (not valid with /E, /G, /R, /P, or /D).
    /E            Edit ACL instead of replacing it.
    /C            Continue on access denied errors.
    /G user:perm  Grant specified user access rights.
                  Perm can be: R  Read
                               W  Write
                               C  Change (write)
                               F  Full control
    /R user       Revoke specified user's access rights (only valid wi
+th /E).
    /P user:perm  Replace specified user's access rights.
                  Perm can be: N  None
                               R  Read
                               W  Write
                               C  Change (write)
                               F  Full control
    /D user       Deny specified user access.
 Wildcards can be used to specify more that one file in a command.
 You can specify more than one user in a command.

 Abbreviations:
    CI - Container Inherit.
         The ACE will be inherited by directories.
    OI - Object Inherit.
         The ACE will be inherited by files.
    IO - Inherit Only.
         The ACE does not apply to the current file/directory.
    ID - Inherited.
         The ACE was inherited from the parent directory's ACL.

C:\Users\Roboticus>
[download]

Hmmm ... whaddaya know. It's now telling me that cacls is deprecated. Ah, well, if you're on a recent box, try the Icacls command, or cacls if you're on an older one. I didn't intend to do it twice, but that's the way it goes. So here's the output (basically the same) and help screen for Icacls (much more detailed, with examples):

C:\Users\Roboticus>Icacls Music
Music Roboticus-PC\Roboticus:(I)(OI)(CI)(F)
      NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
      BUILTIN\Administrators:(I)(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files
C:\Users\Roboticus>Icacls

ICACLS name /save aclfile [/T] [/C] [/L] [/Q]
    store the the acls for the all matching names into aclfile for
    later use with /restore.

ICACLS directory [/substitute SidOld SidNew [...]] /restore aclfile
                 [/C] [/L] [/Q]
    applies the stored acls to files in directory.

ICACLS name /setowner user [/T] [/C] [/L] [/Q]
    changes the owner of all matching names.

ICACLS name /findsid Sid [/T] [/C] [/L] [/Q]
    finds all matching names that contain an ACL
    explicitly mentioning Sid.

ICACLS name /verify [/T] [/C] [/L] [/Q]
    finds all files whose ACL is not in canonical for or whose
    lengths are inconsistent with ACE counts.

ICACLS name /reset [/T] [/C] [/L] [/Q]
    replaces acls with default inherited acls for all matching files

ICACLS name [/grant[:r] Sid:perm[...]]
       [/deny Sid:perm [...]]
       [/remove[:g|:d]] Sid[...]] [/T] [/C] [/L] [/Q]
       [/setintegritylevel Level:policy[...]]

    /grant[:r] Sid:perm grants the specified user access rights. With 
+:r,
        the permissions replace any previouly granted explicit permiss
+ions.
        Without :r, the permissions are added to any previously grante
+d
        explicit permissions.
    /deny Sid:perm explicitly denies the specified user access rights.
        An explicit deny ACE is added for the stated permissions and
        the same permissions in any explicit grant are removed.

    /remove[:[g|d]] Sid removes all occurrences of Sid in the acl. Wit
+h
        :g, it removes all occurrences of granted rights to that Sid. 
+With
        :d, it removes all occurrences of denied rights to that Sid.

    /setintegritylevel [(CI)(OI)]Level explicitly adds an integrity
        ACE to all matching files.  The level is to be specified as on
+e
        of:
            L[ow]
            M[edium]
            H[igh]
        Inheritance options for the integrity ACE may precede the leve
+l
        and are applied only to directories.

    /inheritance:e|d|r
        e - enables inheritance
        d - disables inheritance and copy the ACEs
        r - remove all inherited ACEs


Note:
    Sids may be in either numerical or friendly name form. If a numeri
+cal
    form is given, affix a * to the start of the SID.

    /T indicates that this operation is performed on all matching
        files/directories below the directories specified in the name.

    /C indicates that this operation will continue on all file errors.
        Error messages will still be displayed.

    /L indicates that this operation is performed on a symbolic link
       itself versus its target.

    /Q indicates that icacls should supress success messages.

    ICACLS preserves the canonical ordering of ACE entries:
            Explicit denials
            Explicit grants
            Inherited denials
            Inherited grants

    perm is a permission mask and can be specified in one of two forms
+:
        a sequence of simple rights:
                F - full access
                M - modify access
                RX - read and execute access
                R - read-only access
                W - write-only access
        a comma-separated list in parenthesis of specific rights:
                D - delete
                RC - read control
                WDAC - write DAC
                WO - write owner
                S - synchronize
                AS - access system security
                MA - maximum allowed
                GR - generic read
                GW - generic write
                GE - generic execute
                GA - generic all
                RD - read data/list directory
                WD - write data/add file
                AD - append data/add subdirectory
                REA - read extended attributes
                WEA - write extended attributes
                X - execute/traverse
                DC - delete child
                RA - read attributes
                WA - write attributes
        inheritance rights may precede either form and are applied
        only to directories:
                (OI) - object inherit
                (CI) - container inherit
                (IO) - inherit only
                (NP) - don't propagate inherit
Examples:

        icacls c:\windows\* /save AclFile /T
        - Will save the ACLs for all files under c:\windows
          and its subdirectories to AclFile.

        icacls c:\windows\ /restore AclFile
        - Will restore the Acls for every file within
          AclFile that exists in c:\windows and its subdirectories

        icacls file /grant Administrator:(D,WDAC)
        - Will grant the user Administrator Delete and Write DAC
          permissions to file

        icacls file /grant *S-1-1-0:(D,WDAC)
        - Will grant the user defined by sid S-1-1-0 Delete and
          Write DAC permissions to file

C:\Users\Roboticus>
[download]

It's long, hence the readmore tags...

Note [1]: There's an interesting discussion on Windows ACL-based permissions in the cygwin documentation, so if you're interested, give it a read. (I don't recall the link, and I'm sure you're as good with Google as I am...)

I hope this is helpful...

...roboticus

Comment on Re: mkdir() problem on windows Select or Download Code

Replies are listed 'Best First'.
Re^2: mkdir() problem on windows by myuserid7 (Scribe) on Nov 21, 2010 at 14:59 UTC
that's it! `cacls` was the trick. `use File::Copy; mkdir "test"; open (PH, "\|cacls test /t/ /g VORDEFINIERT\Benutzer:F"); print PH "j\r\n"; close PH; move ('movable', 'test/mov');` [download] works fine! (I'm writing a 'j' to the process because i didn't find a switch to turn off the 'are you sure' question german) Thanks alot to all of you, especiallly roboticus have a nice day!	[reply] [d/l] [select]
Re^3: mkdir() problem on windows by cdarke (Prior) on Nov 21, 2010 at 17:45 UTC
See http://support.microsoft.com/kb/135268. Alternatively use xcacls.exe from the Windows Resource Kit - this version does not prompt.	[reply]
Re^2: mkdir() problem on windows by BrowserUk (Patriarch) on Nov 21, 2010 at 03:05 UTC
Windows permissions can be peculiar1, so it could be a problem with your security settings and such. Nice theory, but either the OP is setting the permission explicitly, or he is inheriting them. Were he setting them explicitly, we might assume that he might mention it. If he is inheriting them, then creating a file within a subdirectory, will be subject to the same permissions as creating that directory within the CWD. Ie. If he can create the subdirectory, he'd be able to create a file within it. Attributing this to "windows peculiar permissions" is ... Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP an inspiration; A true Folk's Guy	[reply]
Re^3: mkdir() problem on windows by roboticus (Chancellor) on Nov 21, 2010 at 03:33 UTC
BrowserUk: Yep, I mentioned it to him precisely because he may be inheriting some permissions he doesn't know about. I've been bitten by some odd Windows permissions in locked-down corporate environments, and nothing in the OP led me to believe that he was aware of those issues. ...roboticus Update: I think it may be possible to get that behaviour from the Windows permissions, but I'm by no means knowledgeable enough about them to state it with any certainty. Update: I've been reading the Icacls stuff posted, and it appears that if a directory had the AD privilege, but not the WD privilege, then they would be able to create a directory but not a file in that directory.	[reply]
Re^4: mkdir() problem on windows by BrowserUk (Patriarch) on Nov 21, 2010 at 12:04 UTC
t appears that if a directory had the AD privilege, but not the WD privilege, then they would be able to create a directory but not a file in that directory. Not so. To the best of my ability to verify this--it's a pain to do--there is no combination of inherited ACLs that will allow you to create a directory and then not be able to create a file within that directory. The only circumstances I can envisage whereby this situation might come about without explicit setting of ACLs by the OP, is via Perl's emulation of the umask thing; or perhaps via cygwin's emulation of persistent umasks. But that all I can say on the subject as I'm not sufficiently conversant with the real thing to try and access whether the emulations are screwed or not. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP an inspiration; A true Folk's Guy	[reply]


Perl Monk, Perl Meditation
	PerlMonks