Bug #93419
Updated by Sybille Peters about 3 years ago
php typo3/sysext/core/bin/typo3 cleanup:orphanrecords --dry-run -vvv showed several records as orphans which where not orphans. On closer examination it appears that these records were created / changed while the script ran. h2. Possible concequences Because of this, some non-orphans may get deleted unless the TYPO3 backend is locked during the check! h2. Examples: 1. sys_history <pre> ! [NOTE] Found 245 orphan records in table "sys_history" with following ids: 792749, 792750, 792751, 792752, 792753, ! 792754, 792755, 792756, 792757, 792758, 792759, 792760, 792761, 792762, 792763, 792764, 792765, 792766, ! 792767, 792768, 792769, 792770, 792771, 792772, 792773, 792774, 792775, 792776, 792777, 792778, 792779, ! 792780, 792781, 792782, 792783, 792784, 792785, 792786, 792787, 792788, 792789, 792790, 792791, 792792, ! 792793, 792794, 792795, 792796, 792797, 792798, 792799, 792800, 792801, 792802, 792803, 792804, 792805, ! 792806, 792807, 792808, 792809, 792810, 792811, 792812, 792813, 792814, 792815, 792816, 792817, 792818, ! 792819, 792820, 792821, 792822, 792823, 792824, 792825, 792826, 792827, 792828, 792829, 792830, 792831, ! 792832, 792833, 792834, 792835, 792836, 792837, 792838, 792839, 792840, 792841, 792842, 792843, 792844, ! 792845, 792846, 792847, 792848, 792849, 792850, 792851, 792852, 792853, 792854, 792855, 792856, 792857, ! 792858, 792859, 792860, 792861, 792862, 792863, 792864, 792865, 792866, 792867, 792868, 792869, 792870, ! 792871, 792872, 792873, 792874, 792875, 792876, 792877, 792878, 792879, 792880, 792881, 792882, 792883, ! 792884, 792885, 792886, 792887, 792888, 792889, 792890, 792891, 792892, 792893, 792894, 792895, 792896, ! 792897, 792898, 792899, 792900, 792901, 792902, 792903, 792904, 792905, 792906, 792907, 792908, 792909, ! 792910, 792911, 792912, 792913, 792914, 792915, 792916, 792917, 792918, 792919, 792920, 792921, 792922, ! 792923, 792924, 792925, 792926, 792927, 792928, 792929, 792930, 792931, 792932, 792933, 792934, 792935, ! 792936, 792937, 792938, 792939, 792940, 792941, 792942, 792943, 792944, 792945, 792946, 792947, 792948, ! 792949, 792950, 792951, 792952, 792953, 792954, 792955, 792956, 792957, 792958, 792959, 792960, 792961, ! 792962, 792963, 792964, 792965, 792966, 792967, 792968, 792969, 792970, 792971, 792972, 792973, 792974, ! 792975, 792976, 792977, 792978, 792979, 792980, 792981, 792982, 792983, 792984, 792985, 792986, 792987, ! 792988, 792989, 792990, 792991, 792992, 792993 </pre> All of these had a timestamp (tstamp) which showed that these were created during the check: <pre><code class="sql"> select uid,FROM_UNIXTIME(tstamp),pid from sys_history where uid in ( ... </code></pre> 2. Same goes for sys_log Here 526 records were reported as orphans Orphans were also reported for sys_file (where the pid is also 0) 2. 3. Also, orphan records were shown in tt_content: 484 Most of these were orphans. But also non-orphans were detected: select t.uid,t.pid,FROM_UNIXTIME(t.crdate),FROM_UNIXTIME(t.tstamp),t.deleted,p.title,p.deleted from tt_content t inner join pages p on t.pid=p.uid and t.uid in (...) and p.deleted=0; Again, the create time (crdate) was during the checking. h2. Reason for problem I think the problem is the order in which the checking is performed. First, all pids are collected. Then the check is performed. If some new pages were created after the first check, these are not in the list. That does not really explain the falsely reported ones in sys_log and sys_history. In that case, pid is always 0.