Temporary file issues and 512 bytes truncation

[Jon78]

Hi,

We use csync2 together with lsyncd to synchronize 80G of data across three webservers. Ever since we dist-upgraded from Debian Jessie to Debian Stretch (and went from csync2 1.34 to 2.0), we've been experiencing issues with temporary files being synced:

Fri Aug 2 16:30:54 2019 Normal: Processing syncing list: web01:/srv/production.scholieren.com/storage/app/public/images/avatars/222781_628213156475615611jpg_500x_100.jpg Fri Aug 2 16:31:25 2019 Normal: Finished events list = 0 Fri Aug 2 16:31:26 2019 Normal: Processing syncing list: web01:/srv/production.scholieren.com/storage/app/public/images/avatars/.222781_628213156475615611jpg_500x_100.jpg.Ps0JDy web01:/srv/production.scholieren.com/storage/app/public/images/avatars/.222781_628213156475615611jpg_500x_100.jpg.h9ZPzU web01:/srv/production.scholieren.com/storage/app/public/images/avatars/.222781_628213156475615611jpg_500x_100.jpg.r2jZvg web01:/srv/production.scholieren.com/storage/app/public/images/avatars/.222781_628213156475615611jpg_500x_100.jpg.xsOFUC web01:/srv/production.scholieren.com/storage/app/public/images/avatars/.222781_628213156475615611jpg_500x_100.jpg.12ZvjZ web01:/srv/production.scholieren.com/storage/app/public/images/avatars/.222781_628213156475615611jpg_500x_100.jpg.RILpIl Fri Aug 2 16:31:58 2019 Normal: Finished events list = 0

We could exclude dot-files, but that would also exclude .htaccess for example. We've tried setting the tempdir-variabele, but this led to all sorts of problems (all remote files being truncated to 512 bytes was the funniest one).

Why is this suddenly the case? Maybe we've missed a change in the way the flags work? Is there an upgrade guide for 2.0? Please advise.

Jon

[lge]

Are we talking about temp files created by csync2, or by some application?

Options: pattern exclude them in csync2, or tell your app to create them elsewhere (if these are app temp files), or use a tempdir /on the same file system!/ (If these are csync2 temp files).

The truncated to 512 bytes thing: There used to be a bug where shown diffs would be truncated, but the actual file transfer would be ok. And there used to be a bug where the copy from temp file into actual file would do that. The copy is not necessary if the temp file can be renamed into place. Both bugs have been fixed since years already, afaik, so tell your vendor/distribution to update their packages.

[Jon78]

Are we talking about temp files created by csync2, or by some application? Options: pattern exclude them in csync2, or tell your app to create them elsewhere (if these are app temp files), or use a tempdir /on the same file system!/ (If these are csync2 temp files). The truncated to 512 bytes thing: There used to be a bug where shown diffs would be truncated, but the actual file transfer would be ok. And there used to be a bug where the copy from temp file into actual file would do that. The copy is not necessary if the temp file can be renamed into place. Both bugs have been fixed since years already, afaik, so tell your vendor/distribution to update their packages. …

The temporary files are created by csync2 (or rather rsync, since they follow the same temporary file naming structure) and all newly created or updated files are affected. We've tried setting the tempdir variable to a non-synced directory (/tmp/csync-partial), but this had serious side-effects. I'll try installing csync2 manually, see if this helps. Thanks!

[moko-als]

And there used to be a bug where the copy from temp file into actual file would do that.

Bug in update.c / csync_diff() was indeed fixed: https://github.com/LINBIT/csync2/commit/f177b72e56c6200707df1f340eccf5273ee8173d

But exactly the same issue exist in rsync.c / csync_rs_patch(). And this leads to 512 bytes truncation when tempdir is on another filesystem and rename() fails with EXDEV. Same fix helps:

--- rsync.c.orig 2020-09-16 13:43:42.000000000 +0300 +++ rsync.c 2020-09-16 14:07:30.869998322 +0300 @@ -788,7 +788,7 @@ */ rewind(new_file); while ( (rc = fread(buffer, 1, 512, new_file)) > 0

• && fwrite(buffer, rc, 1, basis_file) == rc )
• && fwrite(buffer, 1, rc, basis_file) == rc ) ; / at least retain the temp file, if something went wrong. / if (ferror(new_file) || ferror(basis_file)) {

[lge]

Uh-oh. I introduced that regression myself, when adding the "error check" in 6f5ba5e :-O :-( Thanks.

[Jon78]

It is never too late to correct a mistake

[lge]

closed by fe807ec5023e639972dd45a7b31ec70fdf26820a