Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

mkdir() problem on windows

by myuserid7 (Scribe)
on Nov 20, 2010 at 21:58 UTC ( [id://872705]=perlquestion: print w/replies, xml ) Need Help??

myuserid7 has asked for the wisdom of the Perl Monks concerning the following question:

Hello dear Perlmonks!

I think my problem is relatively simple, but after searching the net for two hours I give up and come to you. So:

I'm having a part of a script, running on Windows XP, that creates a new directory in a existing directory. So far, so good. But when I now try move a file into this new directory, I'm getting a "Permission denied" - Error. And it's correct, I tested it and found out, that every directory I create with mkdir() becomes write-protected in general (Meaning the Wirte-Protect-Checkbox on the first page of the file/folder properties - NOT the permissions on Security Page).

Now - how can I remove the general write protection from the folders, I created with mkdir() ?

thanks for any help or tipps

Replies are listed 'Best First'.
Re: mkdir() problem on windows
by roboticus (Chancellor) on Nov 21, 2010 at 02:52 UTC

    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

    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>

    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):

    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

      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');

      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!

      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.

        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.

Re: mkdir() problem on windows
by BrowserUk (Patriarch) on Nov 21, 2010 at 00:08 UTC

    Your problem description doesn't reflect my experience:

    c:\test>dir /b fred File Not Found c:\test>perl -E"mkdir 'fred' or die $!; mkdir 'fred/bill' or die $!" c:\test>dir /b fred bill c:\test>dir /b fred\* bill

    The only thing that I can see that might change the above, is if the code you are using has set the umask?


    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.
Re: mkdir() problem on windows
by AnomalousMonk (Archbishop) on Nov 21, 2010 at 00:03 UTC

    I don't know what your problem may be, but FYI the following works for me under Windows 7 and Strawberry 5.10.1.0:

    >perl -wMstrict -le "my $dir = 'test'; mkdir $dir or die qq{mkdir: $!}; my $bt = `copy junque $dir`; print qq{[[$bt]]} if $bt; print `dir $dir`; print `fc junque test\\*`; " [[ 1 file(s) copied. ]] Volume in drive C is Acer Volume Serial Number is 9480-355B Directory of c:\@Work\Perl\monks\oko1\test 11/20/2010 06:54 PM <DIR> . 11/20/2010 06:54 PM <DIR> .. 11/20/2010 06:49 PM 20 junque 1 File(s) 20 bytes 2 Dir(s) 257,344,540,672 bytes free Comparing files junque and TEST\junque. FC: no differences encountered
Re: mkdir() problem on windows
by PeterPeiGuo (Hermit) on Nov 20, 2010 at 22:26 UTC

    One way is to run DOS attrib command from your perl. Look up attrib command.

    Peter (Guo) Pei

      Thanks for the quick reply!

      I tried this out, but it seems not to work, at least not in my case

      D:\dev\perl>perl -e "mkdir('test');" D:\dev\perl>attrib test D:\dev\perl\dirtreeByTag\test

      DOS attrib shows no +R (the flag for read-only) - but the Windows property Dialog shows "semi-checked" checkbox for write protection (meaning the background of the box is gray, but it is checked)

      I Think this must mean that there are differences between the DOS-available attributes and the ones windows sets...

      I will look further with this information and let you know if I find something.

      In the mean time I'm looking forward for any other answers, as everybody here does always ;-)

      greetings to all of you

      I now tried to fix it with Win32::File::Object - and found out that I indeed can set and unset attributes like HIDDEN but whatever I try it does not work for READONLY

        Well... at least not for directories, as I found out now. With regular files all works just fine...

        Could this be a bug in the Win32::File / Win32::File::Object Module?

Re: mkdir() problem on windows
by Anonymous Monk on Nov 20, 2010 at 23:57 UTC
    Hi,

    How are you using mkdir?

    Are you using the

        $ret = mkdir( $dirname, 0777 );

    form?

    Actually I'm not sure if it works on Windows, but it's woth a go.

    J.C.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://872705]
Approved by planetscape
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2024-03-29 11:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found