Cousin Ricky <ric### [at] yahoocom> wrote:
> I'm using GNU/Linux, where file undeletion requires a 3-credit semester
> course to learn how to do it.

Sorry to disappoint you, but there is no need for a dedicated course. You got
two options.

First one (under Linux Mint with Caja file manager) is found in the Edit menu,
option Undo (accessible by Ctrl+Z). After some delay, the last deleted
 file should reappear ...

Second option is a bit more involving: open Trash in your file manager and sort
it by date (from newest to oldest). You could find the requested file near the
top of the list of files, which appears after a more or less long list of
folders.

The second option can help you recover a file deleted some time ago. The first
one is an immediate action.

I hope this will help you a little. BTW, no shame having fat fingers: it happens
to me from time to time !

Kelumden a.k.a. Vincent Dumont

Post a reply to this message

On 27.08.2024 15:36, Kelumden wrote:

> The second option can help you recover a file deleted some time ago. The first
> one is an immediate action.

According to description provided, file was not deleted. File was 
overwritten.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 2024-08-27 08:36 (-4), Kelumden wrote:
> 
> First one (under Linux Mint with Caja file manager) is found in the Edit menu,
> option Undo (accessible by Ctrl+Z). After some delay, the last deleted
>  file should reappear ...

If I had known 3 years ago what I know today, I would have bought a
Linux Mint machine.  However, the KDE Dolphin file manager has the same
feature.  Not that it matters; see below.

> Second option is a bit more involving: open Trash in your file manager and sort
> it by date (from newest to oldest). You could find the requested file near the
> top of the list of files, which appears after a more or less long list of
> folders.

The problem is that these only work if you delete the file via the file
manager, or via an app that uses the trash folder (such as Gwenview).
This file was deleted by POV-Ray as part of the process of rendering a
new image.  It never went to the trash.

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> ...
> The problem is that these only work if you delete the file via the file
> manager, or via an app that uses the trash folder ...

has me wonder if, perhaps, using a filesystem which supports "snapshots"[*], one
could set up a trigger, to fire when POV-Ray closes the output file.  (wild
speculation :-))

[*] like 'btrfs' and 'zfs'.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> > ...
> > The problem is that these only work if you delete the file via the file
> > manager, or via an app that uses the trash folder ...
>
> ... perhaps, using a filesystem which supports "snapshots"[*], ...

on reflection, overkill.  a bit of scripting might do though, Tcl to the rescue
:-), the first example in particular:
<https://tcl-inotify.sourceforge.net/>


regards, jr.

Post a reply to this message

On 8/25/24 12:37, Cousin Ricky wrote:
> I just accidentally destroyed a 14 hour render, by accidentally
> repeating the render command--within seconds of it completing, so no
> backup.  Don't you hate when that happens?
> 
> I'm using GNU/Linux, where file undeletion requires a 3-credit semester
> course to learn how to do it.
> 
> Do you with the 3 week renders ever have that problem?

I've read through this discussion on looking in on the news forums today.

Off the top of my head, I think situation on accidentally re-starting a 
long render isn't all that dire(*) these days - as long as you don't panic.

Prior to v3.7 and smp / threads, the image file was written as the image 
pixels were rendered; an accidental re-start of a long render was more 
of a problem because the output image file was almost immediately 
written to after the render phase started. Today, the image and state 
are stored internally and written to the output image file only after 
the last block of the image completes.

On Linux / Unix at least, the reality is even after the fat finger 
render phase starts and opens the output file, the prior image file will 
exist until the file handle is closed at the end of the render phase(**).

Let the accidental re-render run (or better pause it) until you've 
copied / moved the existing image file somewhere safe - then abort the 
fat finger render.

Bill P.

(*) - POV-Ray versions using a gui might make me a liar, if the gui does 
something with the image output file itself on the re-render.

(**) - Given most all default file buffering schemes.

Post a reply to this message

On 8/27/24 17:03, jr wrote:

>> The problem is that these only work if you delete the file via the file
>> manager, or via an app that uses the trash folder ...
> 
> has me wonder if, perhaps, using a filesystem which supports "snapshots"[*],

    Or use a real OS who do versionning, like VAX/VMS :)


-- 
+---------------------------------------------------------------------+
|          https://tube.interhacker.space/a/tth/video-channels        |
+---------------------------------------------------------------------+

Post a reply to this message

On 2024-08-27 18:52 (-4), William F Pokorny wrote:
> 
> On Linux / Unix at least, the reality is even after the fat finger
> render phase starts and opens the output file, the prior image file will
> exist until the file handle is closed at the end of the render phase(**).
> 
> Let the accidental re-render run (or better pause it) until you've
> copied / moved the existing image file somewhere safe - then abort the
> fat finger render.

This has not been my experience.  My observation is that the image file
disappears at the end of the parse phase of the new render.

Post a reply to this message

On 2024-08-27 19:25 (-4), tTh wrote:
> On 8/27/24 17:03, jr wrote:
> 
>>> The problem is that these only work if you delete the file via the file
>>> manager, or via an app that uses the trash folder ...
>>
>> has me wonder if, perhaps, using a filesystem which supports
>> "snapshots"[*],
> 
>    Or use a real OS who do versionning, like VAX/VMS :)

:-O

I didn't realize VMS was still around!

Yes, that is a useful feature of VMS.

Post a reply to this message

On 8/27/24 22:05, Cousin Ricky wrote:
> On 2024-08-27 18:52 (-4), William F Pokorny wrote:
>>
>> On Linux / Unix at least, the reality is even after the fat finger
>> render phase starts and opens the output file, the prior image file will
>> exist until the file handle is closed at the end of the render phase(**).
>>
>> Let the accidental re-render run (or better pause it) until you've
>> copied / moved the existing image file somewhere safe - then abort the
>> fat finger render.
> 
> This has not been my experience.  My observation is that the image file
> disappears at the end of the parse phase of the new render.
> 

Thanks for questioning.

I didn't expect any difference on this between yuqk and official 
releases with this, but apparently something I've done and forgotten; Or 
an unexpected side effect of something I've done over time in yuqk, 
makes it alone behave as I described.

The official releases do appear to erase the file at the start of the 
rendering phase. (Ubuntu 22.04 using several official v3.7 & v3.8 releases)

Bill P.

Post a reply to this message