POV-Ray : Newsgroups : povray.general : Stupid fatfingers Server Time
3 Nov 2024 14:42:04 EST (-0500)
  Stupid fatfingers (Message 11 to 16 of 16)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: jr
Subject: Re: Stupid fatfingers
Date: 27 Aug 2024 11:45:00
Message: <web.66cdf40e8092bf0cf5bfc9b06cde94f1@news.povray.org>
"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

From: William F Pokorny
Subject: Re: Stupid fatfingers
Date: 27 Aug 2024 18:52:31
Message: <66ce58af$1@news.povray.org>
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

From: tTh
Subject: Re: Stupid fatfingers
Date: 27 Aug 2024 19:25:25
Message: <66ce6065$1@news.povray.org>
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

From: Cousin Ricky
Subject: Re: Stupid fatfingers
Date: 27 Aug 2024 22:05:09
Message: <66ce85d5$1@news.povray.org>
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

From: Cousin Ricky
Subject: Re: Stupid fatfingers
Date: 27 Aug 2024 22:15:10
Message: <66ce882e$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: Stupid fatfingers
Date: 27 Aug 2024 23:04:35
Message: <66ce93c3$1@news.povray.org>
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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.