I am trying to rsync some files from ext3 to fat32 pen drive. What is
the correct way to do this?
I am currently using, --progress -av --no-o --no-g --exclude '*iso' /ext3 /fat32
Are there any other options I should consider?
TIA
--
Please use reply-all for most replies to avoid omitting the
On Fri 15 Jan 2010, Mag Gam wrote:
I am trying to rsync some files from ext3 to fat32 pen drive. What is
the correct way to do this?
I am currently using, --progress -av --no-o --no-g --exclude '*iso' /ext3
/fat32
Are there any other options I should consider?
--modify-window=2 may
Hi all,
We use rsync to move data from various devices to a single server. Each of
these devices is powered off regularly (at least every day). On the server,
rsync 3.0.5 is started from xinetd with the --daemon argument. The clients
run rsync 3.0.4, protocol 30 (on ARM).
Today I noticed
On Mon, Jan 11, 2010 at 3:12 AM, Matthias Adler rs...@cronic.de wrote:
rsync: read errors mapping filename: Cannot allocate memory (12)
The read errors mapping error is output when the read() calls for a file
returned an error to the sender. The errno (12) is what the OS indicated
for the
On Fri, Jan 1, 2010 at 6:26 AM, Andreas Schildbach andr...@schildbach.dewrote:
In short, I'd like to mimic the behaviour rync has on individual
files (building them as .filename-random and then renaming them to
filename) for the whole destination directory.
The only thing rsync currently
On Sat, Dec 26, 2009 at 6:09 PM, Julius Davies juliusdav...@gmail.comwrote:
I'm curious if the fact maketree.py is GPLv2 causes any trouble for
the rest of rsync (which is GPLv3 or later).
Fortunately that's just a test script, and not even one that is currently
used. So the bundling of a
On Fri, Jan 15, 2010 at 5:26 AM, Jeroen van der Vegt
jeroen.van.der.v...@technolution.nl wrote:
Today I noticed several rsync processes (23 to be exact) running on the
server since as long back as November 2009 (according to ps, and also
/proc/[pid]/stat ). As the clients run for at most a
Hi,
Strace is rather quiet; they all seem to be stuck in this call:
futex(0xc81140, FUTEX_WAIT, 2, NULL
Thats not very useful I suppose, but GDBs output might be:
$ gdb /usr/bin/rsync 26359
#0 0x00e9d402 in __kernel_vsyscall ()
#1 0x00c1dde3 in __lll_lock_wait_private () from
Can anyone suggest a good way to speed up rsync on really large files? In
particular, when I rsync the mail spool directory, I have a few users with
inboxes over 1GB and up and it seems to take a very long time to just
compare the files. Maybe it would be faster to copy from scratch for files
On 01/15/2010 07:22 PM, David Trammell wrote:
Can anyone suggest a good way to speed up rsync on really large
files? In particular, when I rsync the mail spool directory, I have a
few users with inboxes over 1GB and up and it seems to take a very
long time to just compare the files. Maybe it
I could use an ordinary copying script for the mail files, but I figured if
rsync can do it in some more optimal way, I'll stick with it for simplicity
(since it's working great for the several hundred gigs of user files).
I saw the -W option, but I wasn't sure about how it behaves as the man
On 01/15/2010 07:46 PM, David Trammell wrote:
I could use an ordinary copying script for the mail files, but I
figured if rsync can do it in some more optimal way, I'll stick with
it for simplicity (since it's working great for the several hundred
gigs of user files).
I saw the -W option,
On Fri 15 Jan 2010, David Trammell wrote:
I saw the -W option, but I wasn't sure about how it behaves as the
man pages don't have many details, and I thought there might be
other options I missed. For -W the man page just says copy files
whole (w/o delta-xfer algorithm)
Take a moment to
13 matches
Mail list logo
