File moved while being written to, write continues, how is that possible?

[Ralf Mardorf]

On Wed, 24 Mar 2021 10:08:01 +0100, Bo Berglund wrote:
>On Wed, 10 Mar 2021 07:17:55 +0100, Volker Wysk <post at volker-wysk.de>
>wrote:
>
>>Am Mittwoch, den 10.03.2021, 06:59 +0100 schrieb Bo Berglund:  
>>> I have a script that runs ffmpeg to download streaming video hourly.
>>> It is executed as an at job at scheduled times.
>>> 
>>> Today I accidentally moved the resulting file to another folder
>>> before it was completely written, about 10 minutes remained to
>>> write. When I realized what I had done I figured that I have lost
>>> the download, but strangely it continued to grow in size at the new
>>> location! So I moved it back and the download completed and I could
>>> find no errors in the resulting video file.
>>> 
>>> This is really strange to me and something that would never happen
>>> on Windows...
>>>
>>> So now I wonder if this is a built-in feature of Linux generally or
>>> is it caused by the fact that the location of the file is on an NFS
>>> share on an Ubuntu 18 file server?  
>>
>>It's a feature of Linux. Once a file is opened, the path on the
>>(same) disk doesn't matter. An open file (I believe) is internally
>>accessed through its inode, which stays the same.
>>
>>AFAIK, the file even stays alive after it is deleted, until it is
>>closed.  
>
>Today I accidentally deleted a file which was being downloaded by an
>at job... With the above in mind, and since the at job still runs even
>though the result file is now gone from the output folder, is there a
>way to resurrect it and give it a name so it can be viewed?
>
>The way I deleted the file was by issuing
>rm inputvideo_0*
>rather than
>rm inputvideo_0*.mp4
>
>Since the file being downloaded is named inputvideo_0xx.mp4.part while
>it is being downloaded by youtube-dl such a command would have saved
>the file I removed...
>
>So how can I find this file and give it a name?

Note, the mv command within the same partition is atomic, OTOH this
doesn't matter, since mv by one way or the other doesn't run rm before
the copy is finished without an error. The way open files are handled is
important, too, but just because opened files/devices are
"protected", it doesn't mean you can do what you want and always expect
to get what you have got in your mind. I don't understand what you try
to do here, but perhaps you can use a tool for your files system, such
as extundelete, to recover the deleted file, but you shouldn't bet on
this. I try to avoid to run into accidents by using "interactive"
options, such as "rm -i", "mv -i" etc..