Re:GitLab Database Incident – Live Report
by namepros on Tuesday January 31, 2017 @11:43PM
(#13538314)
This sounds good until you consider that many systems are utilizing multiple drives. When someone is expecting to delete a large file and it ends up on a different drive, problems could arise.
[ Parent
| on HN ]
Re:GitLab Database Incident – Live Report
by yorwba on Wednesday February 01, 2017 @12:38AM
(#13538559)
Renaming a file should not move its data, right? So rename the file into .file.$(date -Iseconds).trash (but make sure that no legitimate files are ever named in this pattern). Then put that file path into a global /var/trashlist. To cleanup, you just check that file for expired trash and make the final deletion.
Re:GitLab Database Incident – Live Report
by traviscj on Wednesday February 01, 2017 @08:39AM
(#13540585)
Beware race conditions when writing to /var/trashlist (assuming you mean "a file with one path per line.")
Proposed tweaks: symbolic link into /var/trashlist directory, where the name of the symbolic link is "<timestamp>-<random stub>-<original basename>". Timestamp first so we can stop once we hit the first too-recent timestamp, random stub to unique the original base name if two different files In different directories are deleted at the same timestamp, original file name for inspection.