|
|
|
|
Kann mal jemand in den Code gucken was es wirklich tut? Würde mich jetzt mal interessieren ob das noch aktuell ist, ob es zusätzlich andere Effekte hat oder das was da steht gar nicht (mehr) tut. Das was es laut manpage bewirkt ist ja eher gefährlich und so ziemlich genau das Gegenteil dessen was man erwarten würde. Ich hab die Option auch immer relativ sorglos benutzt bis mir das aufgefallen ist.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TheRealHawk am 04.06.2014 14:57]
|
|
|
|
|
|
rats macht das bestimmt, findet den code hässlich und forked rsync.
|
|
|
|
|
|
|
| Zitat von Oli
rats macht das bestimmt, findet den code hässlich und forked rsync.
| |
Immer gern
ag ignore-errors
~> options.c 944/945
~> internes flag ist ignore_errors
~> generator.c 292 prüft ignore_errors für...
| /* This function is used to implement per-directory deletion, and is used by
* all the --delete-WHEN options. Note that the fbuf pointer must point to a
* MAXPATHLEN buffer with the name of the directory in it (the functions we
* call will append names onto the end, but the old dir value will be restored
* on exit). */ | |
~> in der flist.c wird das flag auch öfter geprüft, soweit ich sehe in Funktionen, die das rsync-Protokoll in Bezug auf Dateilisten zu implementieren scheinen (send_xyz)
Ich würde daher konkludieren, dass die Beschreibung in der Manpage korrekt ist.
| --ignore-errors delete even if there are I/O errors | |
Weiterhin wird gesagt, dass
| If the sending side detects any I/O errors, then the deletion of any files at the destination will be automatically disabled. This is to
prevent temporary filesystem failures (such as NFS errors) on the sending side from causing a massive deletion of files on the destination.
You can override this with the --ignore-errors option. | |
Das passt dann zu den Stellen in der flist.c
Finale Konklusion: --ignore-errors würde ich nicht benutzen.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 04.06.2014 15:51]
|
|
|
|
|
|
Danke. Dann bleibt es auch bei meiner Bewertung: der Name der Option ist verdammt schlecht gewählt.
|
|
|
|
|
|
|
schwach, soweit bin ich auch gekommen. Aber detaillierter weiß ich jetzt auch nicht, was es tut.
|
|
|
|
|
|
|
Was möchtest du denn noch wissen?
|
|
|
|
|
|
|
Ich bin auch bis flist.c gekommen und hatte dann keine Lust mehr, mir genau durchzulesen, was die Funktionen tun. Ich wäre nur nicht so schnell wie du mit einer "Konklusion" gekommen.
tl;dr: nicht nutzen.
|
|
|
|
|
|
|
Übrigens finde ich den Code in der Tat hässlich, überall globale Variablen und nur wenige Kommentare.
(Code+Blank)/Comment ~ 6.5 Codezeilen/Kommentarzeile
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 04.06.2014 16:09]
|
|
|
|
|
|
| Zitat von csde_rats
Übrigens finde ich den Code in der Tat hässlich, überall globale Variablen und nur wenige Kommentare.
| |
Ich finde ihn im Vergleich mit anderem C Code, der auf unseren Linuxen so läuft, relativ gut.
|
|
|
|
|
|
|
Da jede Datei etwa so beginnt...
|
Code: |
extern int am_root;
extern int am_server;
extern int am_daemon;
extern int am_sender;
extern int am_generator;
extern int inc_recurse;
extern int always_checksum;
extern int module_id;
extern int ignore_errors;
extern int numeric_ids;
extern int recurse;
extern int use_qsort;
extern int xfer_dirs;
extern int filesfrom_fd;
extern int one_file_system;
extern int copy_dirlinks;
extern int preserve_uid;
extern int preserve_gid;
extern int preserve_acls;
extern int preserve_xattrs;
extern int preserve_links;
extern int preserve_hard_links;
extern int preserve_devices;
extern int preserve_specials;
extern int delete_during;
extern int missing_args;
extern int eol_nulls;
extern int relative_paths;
extern int implied_dirs;
extern int ignore_perishable;
extern int non_perishable_cnt;
extern int prune_empty_dirs;
extern int copy_links;
extern int copy_unsafe_links;
extern int protocol_version;
extern int sanitize_paths;
extern int munge_symlinks;
extern int use_safe_inc_flist;
extern int need_unsorted_flist;
extern int sender_symlink_iconv;
extern int output_needs_newline;
extern int sender_keeps_checksum;
extern int unsort_ndx;
extern uid_t our_uid;
extern struct stats stats;
extern char *filesfrom_host;
extern char *usermap, *groupmap;
extern char curr_dir[MAXPATHLEN];
extern struct chmod_mode_struct *chmod_modes;
extern filter_rule_list filter_list;
extern filter_rule_list daemon_filter_list;
#ifdef ICONV_OPTION
extern int filesfrom_convert;
extern iconv_t ic_send, ic_recv;
#endif
#define PTR_SIZE (sizeof (struct file_struct *))
int io_error;
int checksum_len;
dev_t filesystem_dev; /* used to implement -x */
struct file_list *cur_flist, *first_flist, *dir_flist;
int send_dir_ndx = -1, send_dir_depth = -1;
int flist_cnt = 0; /* how many (non-tmp) file list objects exist */
int file_total = 0; /* total of all active items over all file-lists */
int file_old_total = 0; /* total of active items that will soon be gone */
int flist_eof = 0; /* all the file-lists are now known */
#define NORMAL_NAME 0
#define SLASH_ENDING_NAME 1
#define DOTDIR_NAME 2
#define MISSING_NAME 3
/* Starting from protocol version 26, we always use 64-bit ino_t and dev_t
* internally, even if this platform does not allow files to have 64-bit inums.
* The only exception is if we're on a platform with no 64-bit type at all.
*
* Because we use read_longint() to get these off the wire, if you transfer
* devices or (for protocols < 30) hardlinks with dev or inum > 2**32 to a
* machine with no 64-bit types then you will get an overflow error.
*
* Note that if you transfer devices from a 64-bit-devt machine (say, Solaris)
* to a 32-bit-devt machine (say, Linux-2.2/x86) then the device numbers will
* be truncated. But it's a kind of silly thing to do anyhow. */
/* The tmp_* vars are used as a cache area by make_file() to store data
* that the sender doesn't need to remember in its file list. The data
* will survive just long enough to be used by send_file_entry(). */
static dev_t tmp_rdev;
#ifdef SUPPORT_HARD_LINKS
static int64 tmp_dev = -1, tmp_ino;
#endif
static char tmp_sum[MAX_DIGEST_LEN];
static char empty_sum[MAX_DIGEST_LEN];
static int flist_count_offset; /* for --delete --progress */
static void flist_sort_and_clean(struct file_list *flist, int strip_root);
static void output_flist(struct file_list *flist); |
|
Stimme ich dir nicht zu.
|
|
|
|
|
|
|
So what, ist halt pragmatisch. Die Lesbarkeit finde ich ok.
|
|
|
|
|
|
|
Dann weißt du ja schon was --ignore-errors macht
So wie ich das sehe wird das rsync-Protokoll da so on-the-fly zusammengeklöppelt mittels der etlichen write_<typ> und read_<typ> Aufrufe, deswegen dürfte es fast unmöglich sein herauszufinden, was ein bestimmtes write_int(f, 0); beim Client bewirkt, ohne die Codebase und die etlichen Pfade durch die Sende und Empfangsfunktionen gut zu kennen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 04.06.2014 16:20]
|
|
|
|
|
|
Wo ich mich ja gar nicht zurecht finde, ist i3pystatus.
|
|
|
|
|
|
|
Das ist doch DEIN Legacy-Code der da alles unleserlich macht!
|
|
|
|
|
|
|
Kann nicht sein, ich benutze unter python nur emojis als Variablennamen.
Ist da echt noch code von mir drin?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Zitat von TheRealHawk
--ignore-errors tut denke ich nicht was du glaubst das es tut.
| |
Das trifft irgendwie auf so ziemlich jede lange rsync-Option zu. --delete und --existing sind imho schonmal diametral zu dem, was ein Nichtkenner erwarten würde. Aber das hat man nach dem ersten Mal drin. An die Überraschungen, die die Pfadsyntax von --exclude und co bereithält kann man sich auch gewöhnen, aber spätestens bei --link-dest ist auch später immer wieder Schicht, wenn stackoverflow down ist.
|
|
|
|
|
|
|
|
|
|
|
| Stephen Bourne's password was litterally "bourne" | |
|
|
|
|
|
|
|
Faulheit ist wohl eine Krankheit, die weder von Schicht, Mileu noch Intelligenz jeden und alles.jpg befällt.
|
|
|
|
|
|
|
Wer kennt ihn nicht...
|
|
|
|
|
|
|
Das Bild ist schlecht skaliert und deshalb ist die Unterschneidung vom Font so kaputt, oder? ODER?
|
|
|
|
|
|
|
|
|
|
|
Myriad Pro
|
|
|
|
|
|
|
naja, da braucht man nichtmal zu wissen, was kerning ist. das sieht doch jeder, dass das scheiße aussieht, wenn buchstaben so zusammenkleben.
|
|
|
|
|
|
|
Was würdet ihr unter einer "revisionsfähigen Benutzerverwaltung" verstehen?
|
|
|
|
|
|
|
etwas, was ein externer Prüfer auditieren kann. Also sollten alle Zugriffe und Änderungen auswertbar protokolliert werden.
|
|
|
|
|
|
|
openssl hat jetzt zweibuchstabige 'minor-minor' Versionen. ._.
OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m.
OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.
|
|
|
|
|
|
|
OpenSSL nervt.
Restart all the services!
|
|
|
|
|
|
Thema: 100 gute Gründe für Linux ( v0.30 gute Gründe für systemd ) |