samba-b...@samba.org wrote:
https://bugzilla.samba.org/show_bug.cgi?id=11101
--- Comment #1 from Jason Pyeron jpye...@pdinc.us ---
this is
https://git.samba.org/?p=rsync-patches.git;a=blob;f=write-devices.diff
using it in production now
I'm am probably confused, but it looks like this
samba-b...@samba.org wrote:
https://bugzilla.samba.org/show_bug.cgi?id=10857
--- Comment #4 from samba@tange.dk samba@tange.dk ---
Can we start by agreeing that rsync _could_ be aware that it is starting a
remote shell and thus _could_ quote anything that needed quoting?
---
No.
I have a problem similar to this bug, not sure if it is the same bug or
not, the consequences
in my case are killing off a daily snapshot mechanism.
As mentioned in the Concern rsync failing to find attributes... thread,
I am doing an rsync from A-B while excluding files
in a --compare-dest
Kevin Korb wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The rsync equivalent to cp -al would be:
rsync -a --link-dest=/path/to/dir1 /path/to/dir1/ /path/to/dir2/
Note that I switched to absolute paths since rsync considers
- --link-dest relative paths to be relative to the target so
I have a dir dir/
with 2 dirs in it a/ and b/.
dir b/ has a file in it 'file'
dir a has a relative symlink to that file:
Ishtar:/tmp ll dir
total 0
drwxrwxr-x 2 20 Mar 26 10:51 a/
drwxrwxr-x 2 17 Mar 26 10:49 b/
Ishtar:/tmp ll dir/{a,b}
dir/a:
total 0
lrwxrwxrwx 1 9 Mar 26 10:51 symfile -
Kevin Korb wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
rsync not needed: cp -al dir1 dir2
Right now, neither is 'cp' (as of V8.21 - V10 inclusive) --
apparently (?) in response to this
article: http://danwalsh.livejournal.com/64493.html.
Right now, 'cp' tries to 'hardlink' to
Perry Smith wrote:
This is my first time to really use rsync. I did small tests to get the
arguments like I wanted and then kicked off the big rsync about 2 and a half
hours ago. So far, it has not copied over any files.
-
Is it really making progress? Or will it take this long to
Was there some reason that patch got dropped?
Otherwise rsync eats up all the buffer memory.
Note -- I tried directio -- didn't work due to alignment
issues -- buffers have to be aligned to sectors.
The kernel, if I remember correctly, has been on again/off again
on requiring alignment on
If I run rsync w/no args I get a help (3.0.7).
It has: (among other things):
-h, --human-readableoutput numbers in a human-readable format
(-h) --help show this help (-h works with no other options)
So ... is it the case that -h with no other options gives help but
It would be 'nice' if there was an option for rsync to ignore case --
Windows
is real lax about what case files are, and often files will end up with
different cases
depending on what util installed a font last.
When you transfer to linux, you end up with 2 (or more) copies of files
with
, on the
rsync list:
Matt McCutchen wrote:
On Mon, 2009-08-24 at 09:43 -0700, Linda A. Walsh wrote:
Maybe rsync could support extattrs on non-supporting fs's with a
.fn.xattr file stored at the same place as the fn:
If a user used a switch to emulate 'xattrs', then on a fs that
didn't support
I wonder why I got an error message from rsync then if the are
supported...
Matt McCutchen wrote:
There are getfattr and setfattr for manipulating extended attributes
from the command line. Were you thinking of something different?
--
Please use reply-all for most replies to avoid omitting
Maybe rsync could support extattrs on non-supporting fs's with a
.fn.xattr file stored
at the same place as the fn:
If a user used a switch to emulate 'xattrs', then on a fs that
didn't support real .xattrs one
could still ACL and other .xattr info. If a user ran rsync w/o that
switch
a compat layer on top of win.
Matt McCutchen wrote:
On Mon, 2009-08-24 at 09:43 -0700, Linda A. Walsh wrote:
Maybe rsync could support extattrs on non-supporting fs's with a
.fn.xattr file stored
at the same place as the fn:
If a user used a switch to emulate 'xattrs', then on a fs
I was just thinking -- would it be possible to just 'emulate' xattrs on
systems that
don't support them natively with a --Xe switch -- that would store the
xattrs
in a file .filename.xattr in the same dir as the copied file. The
switch only be
paid attention to on systems that don't support
I have a similar problem, but it is also in the 'find' command
on a windows box. Are you, per chance, running the cygwin port
of rsync?
Whether or not, you might try a simple experiment -- see if you
can move the affected file(s) using Explorer Windows.
Also check if you can see the correct
16 matches
Mail list logo
