 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/08/2024 19: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?
It's sorrow, but not fatal - 14 hours is not too much. Just start it
again, go to bed, sleep, wake up, have a good breakfast, go for a walk,
get back and it will be ready !
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/08/2024 19: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?
It's sorrowful, but not fatal - 14 hours is not too much. Just start it
again, go to bed, sleep, wake up, have a good breakfast, go for a walk,
get back and it will be ready !
--
YB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoo com> 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?
Now it's time to learn how to make an automatic backup after each render. If you
take a moment chatgpt can create it for you.
BGimeno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoocom> 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?
Oh, I hear you my brother.
http://news.povray.org/povray.windows/thread/%3Cweb.5887512288c6897ec437ac910%40news.povray.org%3E/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25.08.2024 19: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?
Sounds like you are complete computer novice and never pressed Ctrl+S
instead of Ctrl+Z before ;-)
With POVRay I have the opposite problem: parsing starts, takes time, and
stops and I'm going to search for the error, and all I see is
"interrupted by user".
"It's not a brake, it's slow full throttle".
--
Ilyich the Toad
https://dnyarri.github.io/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
