 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
