Displaying 20 results from an estimated 4000 matches similar to: "Unfortunate results from fake-super"
2018 Feb 03
0
Unfortunate results from fake-super
On 03/02/18 13:20, Dave Gordon via rsync wrote:
> When using fake-super mode in an rsync receiver, anything that's neither a
> file nor a directory (e.g. devices, symlinks, etc) is converted into a file,
> and properties such as original ownership, filetype, and permissions are
> stored in a specific extended attribute.
>
> In the case of a symlink, the contents of the link
2018 Feb 05
2
Unfortunate results from fake-super
On 05/02/18 05:53, Wayne Davison wrote:
> On Sat, Feb 3, 2018 at 5:20 AM, Dave Gordon via rsync
> <rsync at lists.samba.org <mailto:rsync at lists.samba.org>> wrote:
>
> [...fake-super symlink saved as a file...]
>
> This results in the copy being world-writable.
>
> Indeed. The file initially gets created as a mode-600 file, but the code
> later
2018 Feb 06
0
Unfortunate results from fake-super
On 05/02/18 23:03, Dave Gordon via rsync wrote:
> On 05/02/18 05:53, Wayne Davison wrote:
>> On Sat, Feb 3, 2018 at 5:20 AM, Dave Gordon via rsync
>> <rsync at lists.samba.org <mailto:rsync at lists.samba.org>> wrote:
>>
>> [...fake-super symlink saved as a file...]
>>
>> This results in the copy being world-writable.
>>
>>
2017 May 26
9
[Bug 12806] New: Deleting in a row of hardlinked snapshots resets file permissions.
https://bugzilla.samba.org/show_bug.cgi?id=12806
Bug ID: 12806
Summary: Deleting in a row of hardlinked snapshots resets file
permissions.
Product: rsync
Version: 3.1.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: core
2015 Oct 11
2
rsync always try change owner and group of symlink in --fake-super mode
Hi all.
I long time discover strange to me behavior. If I add --fake-super
option on both sides rsync start always set owner and group of symlink.
What interesting there no error, but it done each time as it has been
changed.
Simple reproduce:
$ mkdir rsync.symlinks
$ echo 'file content' > rsync.symlinks/file.itself
$ ln -s file.itself rsync.symlinks/file.symlink
Then try to transfer
2008 Mar 04
2
Overwrite target of ln
Hi all,
Sorry if this seems too basic.
But is there a way to overwrite the target of a symbolic link without
first deleting the symlink itself?
For example, if I have this:
public_html -> releases/b2b-20080228
... and there's a new update, I can then just do the following:
$ ln releases/site-latest public_html
I tried using the -f option but it doesn't seem to work as expected.
2017 May 19
3
Samba 4.5.8 ADS user not showing in directory tree - chown "invalid user"
Hi,
I'm currently working on evalutating a AD-Domain for my Department. Since I have a couple of year experince in running a NT-Style Domain, my choice is samba - nowadays AD-DS.
Now I'm stuck, and I would really appreciate some more thoughts and a push in the right direction. :-)
Thank your in advance
Franz
The facts:
A quick test installation is working as expected - Debian Jessie,
2008 Mar 05
0
--fake-super and xattr between Linux and Solaris 10
Hello trusty rsync list,
I'm excited about --fake-super as it will replace too much work with none at
all. I have gotten it to work under linux and I have a fair grasp with what
is happening there. I have a problem, though, and that is, in the long
term, I'll need to archive my Linux systems not to a Linux box, but to a
Solaris 10 box. I understand that Solaris does have extended
2010 Feb 08
0
DO NOT REPLY [Bug 7108] New: --fake-super should be nestable
https://bugzilla.samba.org/show_bug.cgi?id=7108
Summary: --fake-super should be nestable
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P3
Component: core
AssignedTo: wayned at samba.org
ReportedBy: matt at mattmccutchen.net
2010 Feb 08
1
DO NOT REPLY [Bug 7110] New: Symlink fake-super data is silently lost when sys_lsetxattr fails with EPERM
https://bugzilla.samba.org/show_bug.cgi?id=7110
Summary: Symlink fake-super data is silently lost when
sys_lsetxattr fails with EPERM
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P3
Component: core
AssignedTo: wayned at
2010 Feb 08
1
DO NOT REPLY [Bug 7112] New: --fake-super should use default permissions for real files
https://bugzilla.samba.org/show_bug.cgi?id=7112
Summary: --fake-super should use default permissions for real
files
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P3
Component: core
AssignedTo: wayned at samba.org
2013 Jul 19
1
--fake-super locally?
I'm rsyncing files on system1 to its external HD. system2 is remote
and pulls those files from the external HD. system2 does not have
root privileges on system1 so I chown the files to pull. Can I
somehow use --fake-super or something similar to save the original
ownership info to ACLs?
- Grant
2015 Jun 09
0
Problem when excluding unreadable files via pattern and using --fake-super
Hey,
I am experiencing a problem when excluding files that are not readable by
the user on the source side.
rsync version is 3.1.1. on debian jessy.
Here is a "minimal" example:
# preparation:
$ mkdir -p source/subdir
$ touch source/subdir/ignored_file
$ sudo chown root:root source/subdir/ignored_file
$ sudo chmod 600 source/subdir/ignored_file
$ mkdir
2015 Oct 11
0
rsync always try change owner and group of symlink in --fake-super mode
ln -s real-file symlink
file.itself is ./rsync.symlinks/file.itself, but you are trying to link
./file.itself (which presumably doesn't exist) to the real file.
Since a symlink is just a pointer, it gets created, but doesn't point to
any real file.
Try:
ln -s rsync.symlinks/file.itself .
Joe
On 10/11/2015 06:17 AM, Pavel Alexeev wrote:
> Hi all.
>
> I long time discover
2015 Oct 15
0
[Bug 11558] New: rsync always try change owner and group of symlink in --fake-super mode
https://bugzilla.samba.org/show_bug.cgi?id=11558
Bug ID: 11558
Summary: rsync always try change owner and group of symlink in
--fake-super mode
Product: rsync
Version: 3.1.2
Hardware: x64
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: core
2020 Mar 12
0
Would you expect --perms -M--fake-super to set the file mode to the original one?
Permissions don't require super. Any place where permissions can't be
stored certainly can't handle xattrs either. So, I wouldn't expect
--fake-super to affect --perms at all.
On 3/12/20 12:46 PM, Dimitrios Apostolou via rsync wrote:
> rsync --perms -M--fake-super src dst
>
> For me, this command means that rsync should save the original perms in the
> xattr, and
2020 Mar 12
0
Would you expect --perms -M--fake-super to set the file mode to the original one?
I would expect that the sending rsync would only send the perms provided
modified by the --chmod. I wouldn't expect the receiver to even know
the other permissions.
On 3/12/20 1:23 PM, Dimitrios Apostolou via rsync wrote:
> Thank you for the feedback, I'm glad to see that different people see
> the issue
> differently. As a followup question, what would you expect this to do:
2020 Mar 16
0
Would you expect --perms -M--fake-super to set the file mode to the original one?
I don't believe it is possible. I think the misunderstanding stems from
the fact that the permissions are even stored in the xattr. They don't
need to be there but they may as well be. They don't take much space.
The real question would be when rsync reads the file to restore it and
the file perms are different than the ones in the xattr which set does
it use?
On 3/16/20 10:01 AM,
2023 Jul 15
1
Local --fake-super restore failing(?) and creating local directories instead
I am on rsync version 3.2.7 protocol version 31, currently on an Arch
Linux.
The following seems I would expect to copy the contents of 'a' to 'c', based
on my understanding of the the advice of `man rsync`:
-----
mkdir a b c
touch a/hello
rsync -M--fake-super -a a/ b/
rsync --super -M--fake-super -a b/ c/
-----
Instead I see 'c' unchanged, and a garbage directory
2014 Mar 14
3
[Bug 10496] New: --itemize-changes always reports xattr changes with --xattrs --fake-super
https://bugzilla.samba.org/show_bug.cgi?id=10496
Summary: --itemize-changes always reports xattr changes with
--xattrs --fake-super
Product: rsync
Version: 3.1.1
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P5
Component: core
AssignedTo: wayned at