umask in prune command #69

New Issue

Closed

opened 2018-06-14 11:03:43 +00:00 by pavl00 · 3 comments

pavl00 commented 2018-06-14 11:03:43 +00:00

Copy Link

When one repo is used with more clients (umask 007) prune change repository files permissions using default mask (077) and then other clients cant make backups.

In file prune.py in full_command --umask should be added when used different than default.

When one repo is used with more clients (umask 007) prune change repository files permissions using default mask (077) and then other clients cant make backups. In file prune.py in full_command --umask should be added when used different than default.

witten commented 2018-06-15 04:37:49 +00:00

Owner

Copy Link

Thanks for reporting! Makes sense to me. Do you think there's ever a use case for different umasks for create and prune? Or do you think they'd always be the same?

Thanks for reporting! Makes sense to me. Do you think there's ever a use case for different umasks for create and prune? Or do you think they'd always be the same?

pavl00 commented 2018-06-15 08:44:45 +00:00

Author

Copy Link

I think it can be the same umask variable used. I don't see any cases for different umasks - created and modified backup repository should always have the same files permissions.

I think it can be the same umask variable used. I don't see any cases for different umasks - created and modified backup repository should always have the same files permissions.

witten referenced this issue from a commit 2018-06-17 22:13:00 +00:00

Support for Borg prune --umask option (#69).

witten commented 2018-06-17 22:20:06 +00:00

Owner

Copy Link

This is now implemented, and just released as part of borgmatic version 1.2.0! Enjoy.

This is now implemented, and just released as part of borgmatic version 1.2.0! Enjoy.

witten closed this issue 2018-06-17 22:20:06 +00:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

spot-check

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels   

bug

  

data loss

  

design finalized

  

good first issue

  

new feature area

  

question / support

  

security

  

waiting for response

No Label

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

Milestone

Clear milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#69

No description provided.