File Opened in Shared Write mode, may not sync

[therube]

A file opened in a Shared Write mode may cause FFS to not sync that file.

oh, just going to babble...

if a file is open,
in a "shared" manner,

while a forced delete /will/ "delete" the file
the file (handle) still "exists" (if you will)
until the "shared" (handle) has dropped off

& if during that time
you attempt to overwrite the file
you will see something about needing "Admin privileges"
(not sure if you'll see that in FFS or not ?)

scenario:

source x/x.png
target c/out/x.png
Update sync ->

result c/out/x.png

open c/out/x.png in mpv.net
(picture loads in mpv.net)

in FFS (or externally, however...), hard delete c/out/x.png

check directory listing of c/out
- x.png, though hard deleted, still displays
(though it is not actually "there")
try to open c/out/x.png
- fails (because while it still /displays/, it is not actually "there")

in FFS -> Compare

result

FFS shows, both files to "be there", & as equal

source x/x.png
target c/out/x.png

- which is wrong, kind of

the file has been deleted, though it "exists", because there is still
a handle open to it (referencing it) c/o mpv.net
(even though we have done all of this,
we never did anything further with mpv.net after inititally opening the file)

(now close mpv.net, check the directory, & i fact it won't be there any longer
& if you /now/ Compare in FFS, it no longer sees it in target, c/out/,
so will Update copy from source to target & at that point all is good...)

but, if during the time the file was open in mpv.net, you relied upon FFS to
successfully sync, when things were done, in fact that file would not exist
in c/out/...

how is that for an edge case ;-)

now mpv.net opens in a "shared" manner (such that while the file /is/ open
in mpv.net, it is not "locked", so a "delete" does delete, though at the
same time, though deleted, there still exists a file handle still open to it...

similar post in Everything incl. links... At what point in time does a file no longer exist ?

[Plerry]

Not answering your question, but relevant to the topic:
https://freefilesync.org/manual.php?topic=volume-shadow-copy

[Zenju]

while a forced delete /will/ "delete" the file

No, the file is not deleted. It is only *marked* for deletion on handle close.

the file (handle) still "exists" (if you will)
until the "shared" (handle) has dropped off

Exactly.

check directory listing of c/out
- x.png, though hard deleted, still displays
(though it is not actually "there")

The file's still there.

try to open c/out/x.png
- fails (because while it still /displays/, it is not actually "there")

The file is there, but doesn't allow to be opened.

FFS shows, both files to "be there", & as equal

Correct at this point.

now mpv.net opens in a "shared" manner (such that while the file /is/ open
in mpv.net, it is not "locked", so a "delete" does delete,

Deleting an open file is not permitted in general. However, mpv.net went out of its way and granted FILE_SHARE_DELETE.

You've (re-)discovered Windows file deletion handling:
https://devblogs.microsoft.com/oldnewthing/20071109-00/?p=24553