bugrdiff-backup - Bugs: bug #29796, Windows ACLs don't save or restore...

 
 

bug #29796: Windows ACLs don't save or restore the "inherit" flag.

Submitter:  None
Submitted:  Wed 05 May 2010 05:16:15 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 20 May 2022 05:42:30 PM UTC, comment #3: 

This issue has been closed because it hasn't been touched for years, as the development continued on GitHub. If the issue is still present in a recent version, please re-open it under https://github.com/rdiff-backup/rdiff-backup/issues after having made that it's not already reported there.

Eric L. <ericzolf>
Group administrator
Fri 22 Oct 2010 09:05:18 AM UTC, comment #2: 

My mail adress because I did not sign up in this service: mail [AT] dkriesel [DOT] com.

I second that rdiff backup 1.2.8 has its difficulties with file permissions using windows server systems. However, I think we are only talking about a single aspect of the bug here.

In my setup, the target directory tree of the rdiff transmission is set to propagate inheritable permissions (which is common in backuping different servers to a central backup storage system: each single backup source gets its own directory tree which inherits its ACLs from its root). Such setups are most easy to handle (even between to windows machines, like in my case), because one doesn't want to transmit any permissions, inheritances or ACLs at all.

Now sometimes (has to do with deleting and rebuilding files as far as I know, not sure) rdiff messes up the ACLs of single files: It not only disables the inheritance propagation flag that originally has been there, but also messes ob the ACL dataset itself, adding the user group "none". This eventually causes inconsistencies between the main data and the reverse deltas, because during the next run rdiff won't be able to delete that single file whose ACL was messed up if neccessary.

Long story short: Your rdiff repository gets messed up. So, how do I make sure Rdiff itself doesn't touch anything related to the file permissions in a target windows system? For me, the bug does not neccessarily have to be resolved, I will be perfectly fine if maybe someone tells me that I oversaw some flag that prevents Rdiff from touching any ACLs/inheritances/etc.

Anonymous
Wed 05 May 2010 05:18:03 PM UTC, comment #1: 

Pardon me; I should have mentioned: this is with rdiff-backup 1.2.8.

Adam Buchbinder <adambuchbinder>
Wed 05 May 2010 05:16:15 PM UTC, original submission:  

I'm not sure if the flag isn't being saved or isn't being restored, but the flag isn't preserved between backup/restore cycles.

Specifically, given a directory which is set not to allow inheritable permissions to propagate from its parent, the same directory, after being backed up and restored with Windows ACLs enabled, will be set to allow inheritable permissions to propagate. This occurs reliably even given a local-to-local backup and restore cycle on the same filesystem.

This occurs on Windows Server 2003 SP2, using a custom build (see bug 29776) which was made with Python for Windows 2.6.5, PyWin32 built 214 and py2exe 0.6.9. The only difference from the stock downloadable Windows build is that the PyWin32 modules are built in.

The attached screenshot shows the advanced permissions dialog for the original and restored versions of a directory. Apart from that checkbox (and the inherited permissions it causes to be displayed), everything is identical.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #20451:  permission-dialog.png added by None (4KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ericzolf (Posted a comment)
  • -email is unavailable- added by adambuchbinder (Posted a comment)
  • -email is unavailable- added by adambuchbinder
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-05-20 ericzolf Open/ClosedOpen Closed
    2010-05-05 adambuchbinder Carbon-Copy- Added -email is unavailable-
    2010-05-05 None Attached File- Added permission-dialog.png, #20451

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code