From nobody Sun Apr 17 04:13:07 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AA99B11D0AB7 for ; Sun, 17 Apr 2022 04:13:14 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgxWG2306z3Kvt; Sun, 17 Apr 2022 04:13:14 +0000 (UTC) (envelope-from peterj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650168794; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1CCil5IJOdmiGxutW7EOOAcTHO2d7NrLtPrKguNk2Gg=; b=G1zPJssYHvmQ88lckioat9LcvnGmDH7K1nOzgkAWiI5N7JaMjsggnBjOBFtBylV8yNtf/M vl3qpDDU07a1pAc1wsyEp792qdlNfUDmcs5jieLNEzJ3Dfx+ft9JqeTth8zpfIkIX1KCIY wgCplS65AZ5nwQSasbuZhgc9ygxrBebzq6DKHGOrSRDFtbiAVYv+4+MCctsRdzda/LU9gd OERUN5K26XwJk4srwxtIkWGNoX6uBYboxjRbGopr4f+sF3m2tVHr8/PcCqiTHZ12F6hs82 wH+Tt0Xnno2U9CSJH9vacOBPGzpHxaReB9uh2DYi2GoLzPQfhAmBuQ/mJsI19g== Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 37E55A934; Sun, 17 Apr 2022 04:13:12 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Sun, 17 Apr 2022 14:13:07 +1000 From: Peter Jeremy To: Sami Halabi Cc: FreeBSD Current Subject: Re: recover deleted file Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="omXB7HJ7cySNH9NA" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650168794; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1CCil5IJOdmiGxutW7EOOAcTHO2d7NrLtPrKguNk2Gg=; b=QJffk4jni5N2/eLgqT+bOzn4K91Al/citQ6B/LVGMumoKpIr2XPlIMV85pldu2PBacgXmI RjUnhP5lbUSomYTncJNL6ZZSCE+BcJWlODo5BS+bQCfd5bEAUMhY9nFrxXJcNjJ/sPB3n4 BuEIGmuaJbfvp+6LYqdLzOh94AfYcLB9NSI54K99gIhbCfepSBJUMuppkkhjQhFlVlDWYo RouZjTbUcVOyTfe2rgJczuFGA6bj4Hm9P4ukWNryBTJ5wh0VPlfDtaLpGB2Rjp1KVU87Bk fcO/IoUtGCtcfaH9JWB0gQB1yTkqauSYbBOaTlRCbr21q9heZyXbVe+k9as4qA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650168794; a=rsa-sha256; cv=none; b=oG8unwPwyOzqZSdG/jX89y1OGc9cxHA5nR6J67wVuANIbBwRX+jA8mcwFWdo3PJ973YV63 u3H2T6hQKHPU/jOFgcBLLvCOK8M3m9C7oOLeiUyWd9dVDOJpIkrk04YVPbhWEdA2gdeSR0 Y+YvM3n9C502TnpU4uUAVD2hKfHMfFxYXQkTH2xgR9IxAW9JbXHIMFzdfyV680vubl2R0E UkcwKiomEqqOpkKnrBmqLkYcnXxNYiNv1E/gZRze4bKxym6wGMeKO39VJzcqgyD/R03Qsk 9/bB/nFiEmCoFIBzF+2dOCmp95nO6zFWJLimozIZGp6P+HMI40McEMObxECS/g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --omXB7HJ7cySNH9NA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-Apr-17 01:13:02 +0300, Sami Halabi wrote: >I understand its hard to undelete since no one designed UFS/ZFS to do so.. >that why I asked in later replies to see if someone would step in and >implement such a "feature" and I suggested some directions/thoughts. As you point out, neither UFS nor ZFS were designed to support an "undelete" function: Once an inode has no references (open files or directory entries), the inode and all associated data blocks are returned to the free list and could be used by a subsequent allocation. What semantics would you like UFS or ZFS to implement instead? Is it just that the inode and associated data blocks should stay in limbo for some period? If, what controls the period? What if a file is truncated to 0 or overwritten before being unlinked? How much would you be willing to pay for "undelete" functionality? >As soren@ suggested in later reply it maybe would be easier to implement >custom rm script that moves files to "Recycle bin" directory (and empty it >after some period) Alternatively, you could alias "rm" to "rm -i". >but as a programmer I know that perfection is needed :) >so It might start as a simple task and end in many what-if's >(unfortunattly I did my last C programming in late 2003!). This doesn't need to be C. You could do this in your scripting language of choice. Or you could offer to pay someone to do this for you. >What amzes me is that this "feature" was asked too much in the last decade >or two and no one ever implemented it, maybe it's not needed in daily >usage, but in disasters it would be super userful, save admins many time >and nerves.. I went rummaging back through my mail archives and it actually doesn't seem to come up that often. You seem to be about the 3rd person this century on the lists I read. I did find a discussion in zfs-discuss =66rom May/June 2006 about supporting undelete but it seems that no agreement on the desired behaviour was achieved. >For now I did some backup tools locally and used chflags to mark them >undeletable so I wouldn't do that mistake again, You could also consider snapshots - both UFS and ZFS support snapshots. If the information is very critical (you mentioned legal consequences) then you might like to consider real-time replication of the MySQL redo logs to another systems - though that won't necessarily protect you =66rom someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx;" --=20 Peter Jeremy --omXB7HJ7cySNH9NA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmJbk8hfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzS6Lw//RlB1FQSz5/4bt0Z82lMstg9nGtA9JbWTpS9fX1J0mfYQdFzpy0Zv2PIE 3eYGQfBQP1j9qPNgaAasSkW3xpppd/AkDaJvnw8qM4zA6CYesrT9jwjfMnH6p1wI CPVd9DtBZcDbxmSIY/dvFaUUNO8HouR0GR8vtjcihgtjNT/zQ4E93Hz+M0ut4CSz YjsVe5e9hB678JPFHZsynjLnxOlB2G4s8aKZ33KEmdGtTdg3cI5qDx1US68LwNpv VESnKU879F7kSa8j6tY6nRyA/BXH0Hw4g+bnyFf6Pg5Nzwsrf7Cj4LGBUjHpaXZj faXdJtV1y1dXggWrqqWlJ7sQcdQUEi6epnx4PPNlll5/ZwqejQAftbklD27HT3Nz LnCXR5YbVGsKQ0KV/VbHGddhCYx0cfvy0F3oukOIE+TjL8kj6R28++L2HqOond1M dECNHleTqzZDbYN1urgu1QDpVbkar9jzqO9DmWFJAuRzd9FAwCOC0QrtnsDdumyP dtErpdqr3O+t/YOdW40NwHDEdN5QbHgLxcmdAtUsKUl0Oqbb4YUiTaSU+kqTPCF4 VNr8NcU5iMw4LgVJM1B+jimLZB5zDTUo4/DcrGh/mOEC7VFcjRoKzuluqhtNaCdl B6crGesRwG4hwFVMdoohJ9sQWwbQShE7koK7nFPdMcScMZoN6/c= =EuXT -----END PGP SIGNATURE----- --omXB7HJ7cySNH9NA--