[[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Windows DACLs - CHEF-1686


Chronological Thread 
  • From: Christopher Brown < >
  • To: Daniel DeLeo < >
  • Cc: Bryan McLellan < >, Chef Dev < >
  • Subject: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Windows DACLs - CHEF-1686
  • Date: Tue, 17 May 2011 13:50:15 -0700

#2 is not atomic with respect to the final outcome, i.e. the move
might succeed but for some reason icacls does not.
There's at least one failure case in there, and possibly more.
-C

On Tue, May 17, 2011 at 1:33 PM, Daniel DeLeo 
< >
 wrote:
> On Tuesday, May 17, 2011 at 12:18 PM, Bryan McLellan wrote:
>
> http://tickets.opscode.com/browse/CHEF-1686
>
> Because we create files in a temporary directory and then perform an
> atomic move to the destination directory, on Windows the file keeps
> the permissions from where it was created rather than inheriting the
> DACLs of the final destination. Ideally the file would not have any
> ACLs set and would inherit only, unless specified otherwise. There are
> a couple ideas so far, does anyone have input or a better one?
>
> 1) Copy the file instead of move
> Pro: new file inherits DACLs by default
> Con: performance loss due to copy
> Con: [rare] possibility of disk space issue for large file
>
> 2) Use ICACLS to reset the permissions after the move
> Pro: Cheap
> Con: Not ubiquitous. CACLS on XP?
>
> 3) Have Chef use the destination directory as temporary folder but
> create a temporary file there
> Pro: always on the right file system
> Pro: Creates correct DACLs on Windows
> Con: Not atomic
> Con: Cruft could break ".d" style configuration directories.
>
> 4) #3 but just for Windows
> Con: Cruft *still* could break ".d" style configuration directories.
>
> Bryan
>
> #3 is atomic, #1 is not atomic. What we do now is *sometimes* atomic.
>
> --
> Dan DeLeo
>
>



-- 
Christopher Brown, Chief Technical Officer, Opscode, Inc.
T: (425) 502-5522, E: 

IRC, Github: skeptomai
Twitter: @skeptomai



Archive powered by MHonArc 2.6.16.

§