food for thought...
at what point in time does a file no longer exist ?
(when there are no more /links/ to it. but what about, /handles/?)
if a file is opened in a "shared" mode (share write) in one application
& if that same file /IS/ deleted by another application
(which can be done, because the original application opened it in a shared mode)
while that file still "exists", in the realm of the original application
while that file still "exists", as a /directory entry/ on disk
that file does not "exist" as an entity that you can further access - again
- as that file was in fact, "deleted"
- that file can no longer be opened, or viewed, or edited, or even deleted - again
now in Everything, to Everything (or in other applications too, the same as with DIR)
the file /does/ still "exist"
in Everything, if you wanted to copy overtop that file, you're told:
> Destination Folder Access Denied
> You'll need to provide administrator permission to copy to this folder
if you do follow through with the "administrator permission" end of things, that too fails
in DEL, DEL mpv-shot00001.png
> Access is denied.
in IrfanView
> Can't read the file header !
> Unknown file format, empty/damaged or file not found !
in FreeFileSync
> FFS sees that the target, in c:/out/, does exist (even though it is not really "there")
> so does not offer to sync/update that file from source to that target (even though it is not really "there")
> so if you did sync/update (of other files), this particular file would not be included,
> & in the end, it's sync would be a file short
(as soon as the handle to the file drops,
then at that point, the file is "gone",
Everything correctly see it is no longer there,
& likewise all other programs now know it is no longer there, & will then function as expected)
-
copy a file, mpv-shot0001.jpg
say from desktop to c:/out/mpv-shot0001.jpg
open c:/out/mpv-shot0001.jpg in mpv.net
(do nothing further with mpv.net, at this point)
(soft) delete c:/out/mpv-shot0001.jpg - in Everything (or by any other means)
Everything no longer sees the file (as mpv-shot0001.jpg)
- file is deleted as expected & ends up in Recycle.Bin
-
start again
(close mpv.net)
copy a file, mpv-shot0001.jpg
say from desktop to c:/out/mpv-shot0001.jpg
open c:/out/mpv-shot0001.jpg in mpv.net
(do nothing further with mpv.net, at this point)
hard delete c:/out/mpv-shot0001.jpg - from Everything
- note that it still shows up in Everything, still has it's FID (i guess that doesn't auto refresh?)...
- note that cursor dropped to the following line
(an indicator that... something happened, like the file was in fact deleted...)
focus on c:/out/mpv-shot0001.jpg, File | Read Extended Information [Everything 1.5a is needed]
- note that there is no longer a FID (the FID has updated)
- so does that mean the file no longer exists?
file is still open in mpv.net, can still be viewed there
(or if it were a movie, it would still continue to play, there - from beginning to end)
file still has a directory entry
(Everything see's it, DIR see's it, all other program still see it)
yet, it not "there"
as in it can no longer be accessesed by any other program
except for mpv.net, which still does have a /handle/ open to that file
- otherwise, it can't be opened, read, deleted...
- there is no FID, & without a FID, how can a program access it...
-
hard link count, you ask?
- so after hard deleting the file (& refreshing meta info), both FID & link, aren't
no links, then that would tend to indicate that the file no longer exists,
yet until the handle (held by mpv.net) is closed, the file does "exist",
to all other programs
-
"mpv.net" is not an end-all
mpv.net (a GUI front-end for mpv), mpv itself, most likely (Media Player Classic) MPC-BE & HC,
& who knows what else have the potential to cause the same situation to occur?
(Remember that Memorex jingle?)
-
almost forgot...
say you didn't realize that this "file" was not existant (even though most inicators said it was)
& say you updated the source file & wanted to copy that, overwriting the destination,
so from E: to C:, in this case...
- "You'll need to provide administrator permission to copy to this folder"
(& of course, even if you click Continue [to elevate], it still fails, because while the file
does not "exist", there still exists that /handle/ to the file [handle open in mpv.net
- & that causes the overwrite attempt to fail])
did you know that once you've deleted a file, & even though it still "displays" in mpv.net, you can no longer Ctrl+m it.
-
mpv.net media player
At what point in time does a file no longer exist ?
-
- Posts: 684
- Joined: Wed Jan 05, 2022 9:29 pm
Re: At what point in time does a file no longer exist ?
Oooooh! I love philosophical questions.
So, what do you mean by "a file"?
Presumably a general idea of "binary data that used to spin at 7,200 rpm".
But surely at least "the original stored data".
So that "a file" comes into existence on its first save-to-disk.
Then even when the hard disk is corrupted, clever people can recover great wads of the original data from disk sectors that might not be accessible through an operating system's file system.
The ones and zeroes are sill recorded magnetically, but Windows (or Linux or ...) can't deliver them to the normal end-user.
I have recovered so-called lost-data when converting WP5.1DOS documents to MSWord6 documents.
I have located missing data by reading an MSWord document as a binary file.
I think we need to start with a definition of a "file", and differentiate it from "a copy of the data of that file".
As you have pointed out, different applications have different capabilities in tackling access to that stored data, and consequently put up a variety of messages about their various (in)abilities to retrieve that data.
On my laptops, the bulk of my stored data are not recognizable as the original stored data without the assistance of decryption applications such as TrueCrypt and VeraCrypt. If I don't have access to those applications, then does my data cease to exist?
And if so, does it spring back into being once I grab a copy of the decryption application?
Cheers, Chris
Re: At what point in time does a file no longer exist ?
I forgot to link to the associated FreeFileSync thread: File Opened in Shared Write mode, may not sync.
Re: At what point in time does a file no longer exist ?
When deleting a file, the file is marked for deletion.
When all handles to the file are closed, the file is deleted.
It is perfectly valid for multiple handles to be opened for a file when the file is marked for deletion.
Provided the file handles are created with "share delete".
There's a "Delete Pending" property in Everything to find files that are marked for deletion.
There's also an "Opened By" property to show which programs have a handle to the file.
You cannot open files that are marked for deletion (without "share delete").
You'll get error 5: "Access denied" if you try.
Everything doesn't update until it sees a USN Journal event.
A USN Journal event is not created until all handles to the file are closed.
Everything is always lagging behind what is truly on disk.
This lag shouldn't be any more than one second.
Deleting a file from Everything doesn't directly remove the file from your index.
Everything will wait for the external USN Journal event to remove the deleted file from your index.
On NTFS the file is never really physically deleted.
The file entry is only marked as unused.
There are also hard links.
Once the hard link count reaches 0 the file is marked as unused.
(It's a bit more technical as shortnames are hardlinks too)
When all handles to the file are closed, the file is deleted.
It is perfectly valid for multiple handles to be opened for a file when the file is marked for deletion.
Provided the file handles are created with "share delete".
There's a "Delete Pending" property in Everything to find files that are marked for deletion.
There's also an "Opened By" property to show which programs have a handle to the file.
You cannot open files that are marked for deletion (without "share delete").
You'll get error 5: "Access denied" if you try.
Everything doesn't update until it sees a USN Journal event.
A USN Journal event is not created until all handles to the file are closed.
Everything is always lagging behind what is truly on disk.
This lag shouldn't be any more than one second.
Deleting a file from Everything doesn't directly remove the file from your index.
Everything will wait for the external USN Journal event to remove the deleted file from your index.
On NTFS the file is never really physically deleted.
The file entry is only marked as unused.
There are also hard links.
Once the hard link count reaches 0 the file is marked as unused.
(It's a bit more technical as shortnames are hardlinks too)