rsync 3.0.9 partial file left after CTRL-C WITHOUT using --partial

[-]

Hi Justin

No i did a test setup after getting to it in real life. In this test setup:

- rsync (daemonless) is run

- ctrl-c,

- results are checked,

- dest directory is deleted

and so on.


in 50 % the file is left over.


i can reproduce it on a big fat slow (relative to a small ext4
partition on same lvm) xfs-partition.


If i do this on root I even if I manage tp ctrl-c at the right time, I
don't get a temp file left. The test setup is very "clean"

Greetings


Lopiuh


> Is it a new tmp file every time ??  Or is the tmpfile leftover from
> some (probably not reproducible) run?  Are you sure there are no
> "stuck" rsync processes running?  To be sure, you might run sudo lsof
> on that tmpfile.
>
> Justin



On Fri, Apr 5, 2013 at 12:09 PM, Paul Lopez <lopiuh at googlemail.com> wrote:

> Hi folks,
>
> man page says "By default, rsync will delete any partially transferred
> file if the transfer is interrupted"
>
> I have (reproducible) a partial file left, if I do CTRL-C
>
> source-dir: mounted LVM XFS
> dest-dir: see source-dir
> Ubuntu 12.04.1 (LTS)
> kernel 3.2.0-39-generic
>
> command:
> rsync -a
>  /mnt/data/\$sortin_linux/rsnapshot_stable/hourly.1/usr/include/c++/4.4/ext/pb_ds/detail/binary_heap_/
> /mnt/data/delete/
> ^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at
> rsync.c(549) [sender=3.0.9]
>
>
> *Source-Dir:*
> root at yaVDR:~# ls -lsa
>  /mnt/data/\$sortin_linux/rsnapshot_stable/hourly.1/usr/include/c++/4.4/ext/pb_ds/detail/binary_heap_/
>      total 108
>  4 drwxr-xr-x  2 root root 4096 Jul 24  2011 .
>  4 drwxr-xr-x 25 root root 4096 Jul 24  2011 ..
> 12 -rw-r--r--  1 root root 8618 Nov 15  2010 binary_heap_.hpp
>  8 -rw-r--r--  1 root root 4373 Nov 15  2010 const_iterator.hpp
>  8 -rw-r--r--  1 root root 4458 Nov 15  2010 const_point_iterator.hpp
>  8 -rw-r--r--  1 root root 4555 Nov 15  2010
> constructors_destructor_fn_imps.hpp
>  4 -rw-r--r--  1 root root 2509 Nov 15  2010 debug_fn_imps.hpp
>  4 -rw-r--r--  1 root root 2636 Nov 15  2010 entry_cmp.hpp
>  4 -rw-r--r--  1 root root 2599 Nov 15  2010 entry_pred.hpp
>  8 -rw-r--r--  1 root root 5837 Nov 15  2010 erase_fn_imps.hpp
>  4 -rw-r--r--  1 root root 2614 Nov 15  2010 find_fn_imps.hpp
>  4 -rw-r--r--  1 root root 2068 Nov 15  2010 info_fn_imps.hpp
>  8 -rw-r--r--  1 root root 5379 Nov 15  2010 insert_fn_imps.hpp
>  4 -rw-r--r--  1 root root 2280 Nov 15  2010 iterators_fn_imps.hpp
>  4 -rw-r--r--  1 root root 1896 Nov 15  2010 policy_access_fn_imps.hpp
>  8 -rw-r--r--  1 root root 6300 Nov 15  2010 resize_policy.hpp
>  8 -rw-r--r--  1 root root 5311 Nov 15  2010 split_join_fn_imps.hpp
>  4 -rw-r--r--  1 root root 2441 Nov 15  2010 trace_fn_imps.hpp
> root at yaVDR:~#
>
>
> *Dest-Dir (last File is the partial)*
> root at yaVDR:~# ls /mnt/data/delete/ -lsa
> total 44
>  4 drwxr-xr-x 2 root root 4096 Apr  5 12:05 .
>  0 drwxrwxrwx 9 root root  133 Apr  5 12:05 ..
> 12 -rw-r--r-- 1 root root 8618 Nov 15  2010 binary_heap_.hpp
>  8 -rw-r--r-- 1 root root 4373 Nov 15  2010 const_iterator.hpp
>  8 -rw-r--r-- 1 root root 4458 Nov 15  2010 const_point_iterator.hpp
>  8 -rw-r--r-- 1 root root 4555 Nov 15  2010
> constructors_destructor_fn_imps.hpp
>  4 -rw-r--r-- 1 root root 2509 Nov 15  2010 debug_fn_imps.hpp
> * 0 -rw------- 1 root root    0 Apr  5 12:05 .entry_cmp.hpp.543CXr*
> root at yaVDR:~#
>
> It is reproducible, any ideas?
>
> Thanks
>
> lopiuh
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20130406/e7ebfd1f/attachment.html>