Date: Sat, 16 Apr 2022 15:42:04 -0600 From: Warner Losh <imp@bsdimp.com> To: Sami Halabi <sodynet1@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: recover deleted file Message-ID: <CANCZdfqNRD9G-q72mD2ZjUYPwnqwmLLzQeuopxZPdCOEyM=jxA@mail.gmail.com> In-Reply-To: <CAEW%2Boga0BNKZKsnAQWzEqMuUzUwAR293w0XLXM0YhQAsQiESyA@mail.gmail.com> References: <CAEW%2Boga0BNKZKsnAQWzEqMuUzUwAR293w0XLXM0YhQAsQiESyA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000008d8bf305dccc661d Content-Type: text/plain; charset="UTF-8" On Sat, Apr 16, 2022 at 5:24 AM Sami Halabi <sodynet1@gmail.com> wrote: > Hi, > is there anyway easy to restore deleted file by accident in UFS???? > Do you know what the contents of the file is? At least the first, say, ~32k? The problem with unrm for ufs is that the directory entry has the inode number stored in it. Without the inode number, you won't get very far. With the inode number, you can get the first 12 filesystem blocks of the file and the first three indirect blocks. Once you have those, you can reconstruct the file. But only if the inode hasn't been zero'd out (which it likely has, another thing that makes UFS undelete harder). But all hope isn't lost... UFS has a predictable allocation algorithm that lets you get much of the file back (which is why I asked if you know how it should start: you can find where it starts in the data blocks and maybe get lucky with the rest if the data spills into indirect blocks). However, that's only if you don't have TRIM enabled on the filesystem. If you do, then UFS will do a BIO_DELETE of the blocks, which means their contents are likely gone at the drive level. I say likely because there's weasel words in the ATA spec that allows a drive to return the prior contents of the blocks, or all zeros or the drive's initialization pattern (usually all 1's) when the blocks are later read. Same goes for NVMe drives (with the additional constraint it must be deterministic). So there's may still be a chance you can read the old contents, but drives that do that are rare in my experience (which is admittedly quite narrow). But, if you want to use fsdb to try to recover this data, or write your own tools, then you should likely have a copy of the daemon book (The Design and Implementation of the FreeBSD Operating System). It explains a lot of the finer details of UFS and reference to it likely will catch me where my memory isn't quite right in the above descriptions. So, it's for all these reasons you can't find somebody with a unrm command for ufs like you can for DOS or other filesystems. I wish I had a better answer for you. Warner > Sami > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert, FreeBSD SysAdmin Expert > Asterisk Expert > --0000000000008d8bf305dccc661d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sat, Apr 16, 2022 at 5:24 AM Sami = Halabi <<a href=3D"mailto:sodynet1@gmail.com">sodynet1@gmail.com</a>>= wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= =3D"ltr">Hi,<div>is there anyway easy to restore deleted file by accident i= n UFS????</div></div></blockquote><div><br></div><div>Do you know what the = contents of the file is? At least the first, say, ~32k?</div><div><br></div= ><div>The problem with unrm for ufs is that the directory entry has the ino= de number stored in it.</div><div>Without the inode number, you won't g= et very far.</div><div>With the inode number, you can get the first 12 file= system blocks of the file and the</div><div>first three indirect blocks. On= ce you have those, you can reconstruct the file.</div><div><br></div><div>B= ut only if the inode hasn't been zero'd out (which it likely has, a= nother thing that makes</div><div>UFS undelete harder). But all hope isn= 9;t lost...=C2=A0 UFS has a predictable allocation algorithm</div><div>that= lets you get much of the file back (which is why I asked if you know how i= t should start:</div><div>you can find where it starts in the data blocks a= nd maybe get lucky with the rest if the</div><div>data spills into indirect= blocks).</div><div><br></div><div>However, that's only if you don'= t have TRIM enabled on the filesystem. If you do,</div><div>then UFS will d= o a BIO_DELETE of the blocks, which means their contents are</div><div>like= ly gone at the drive level. I say likely because there's weasel words i= n the ATA</div><div>spec that allows a drive to return the prior contents o= f the blocks, or all zeros or</div><div>the drive's initialization patt= ern (usually all 1's) when the blocks are later read. Same</div><div>go= es for NVMe drives (with the additional constraint it must be deterministic= ). So there's</div><div>may still be a chance you can read the old cont= ents, but drives that do that are rare</div><div>in my experience (which is= admittedly quite narrow).</div><div><br></div><div>But, if you want to use= fsdb to try to recover this data, or write your own tools,</div><div>then = you should likely have a copy of the daemon book (The Design and Implementa= tion</div><div>of the FreeBSD Operating System). It explains a lot of the f= iner details of UFS and</div><div>reference to it likely will catch me wher= e my memory isn't quite right in the above</div><div>descriptions.</div= ><div><br></div><div>So, it's for all these reasons you can't find = somebody with a unrm command for ufs</div><div>like you can for DOS or othe= r filesystems. I wish I had a better answer for you.</div><div><br></div><d= iv>Warner</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex"><div dir=3D"ltr"><div>Sami<br clear=3D"all"><div><br></div>-- <br><d= iv dir=3D"ltr"><div dir=3D"ltr"><div><div dir=3D"ltr">Sami Halabi<div>Infor= mation Systems Engineer</div><div>NMS Projects Expert,=C2=A0<span style=3D"= font-size:12.8px">FreeBSD SysAdmin Expert</span></div><div>Asterisk Expert<= /div></div></div></div></div></div></div> </blockquote></div></div> --0000000000008d8bf305dccc661d--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqNRD9G-q72mD2ZjUYPwnqwmLLzQeuopxZPdCOEyM=jxA>