Bug: Cannot delete images from a network share

[Aemony]

It does not seem as if Fly Photos currently support deleting images opened from a network share. Opening and viewing the file works fine but upon trying to delete it using the Delete key, an error message is thrown:

Deletion Failed
The application could not delete the file.
Exeption : Attempted to perform an unauthorized operation.

There's no issues with the access rights to the share in question -- other image viewers can delete it just fine.

[riyasy]

Shall check.`

[ittroll]

I gave this a test. I encountered the same error with BMP, GIF, ICO, JPG and PNG files on a network share, but strangely I could delete ARW files with no problems.

[riyasy]

I think the issue lies in the usage of the StorageFile API (WinRT/UWP) within an unpackaged app when accessing network resources. It is less powerful than the standard FIle operation APIs of c#. I used it to have the feature to delete to Recycle Bin. Normal file operation APIs in c# doesn't have this feature to delete to recycle bin.
Shell automation is another possibility to have the feature to delete to recycle bin. (But I feel reluctant experiencing what has been going on in bug 37)

@ittroll , that seems strange.

[Aemony]

I gave this a test. I encountered the same error with BMP, GIF, ICO, JPG and PNG files on a network share, but strangely I could delete ARW files with no problems.

I can confirm having seen the same behavior once, but no other times... But the fact that I could successfully delete an ARW file once would suggest it's most likely an open handle/resource issue the app is running into.

I monitored the I/O operations a bit with Process Monitor and it would seem that a sharing violation can occur when the app requests delete access to the files located on a network share. Most likely something else in the app, such as one of the dependent codecs, can have an active lock on files on network shares, preventing their deletion.

Attempting to delete a failed file from File Explorer confirms as such as well:

So something in the app or one of its decoders creates a lock on network share files preventing their deletions until those resource handles have been closed.

[riyasy]

Fly takes more time to decode ARW file compared to JPG/PNG etc.. When navigating to an ARW, the user is first presented with the embedded JPG inside the ARW (or a cached preview, if available) and ARW decoding happens in the background. We won't be able to delete the file at that time until the full quality ARW decode is complete.

Fly keeping lock on any file even after the decoding is complete should be a bug.

[riyasy]

@ittroll mentioned ARW files could be deleted while others could not be.. while @Aemony said ARW files were kept open by Fly..

@Aemony @ittroll Can you please confirm it is always the open handle..?

Also can you try delete after taking a photo and waiting for few seconds to make sure image is fully loaded?

[ittroll]

If I skip very quickly through many ARW and immediately press delete then I do see an internal message very briefly.

However, this disappears very quickly after which I can delete the ARW with no problem.

For me, this is different to all other file types which always give the file lock message even after they have been fully loaded.

I can only think that the ARW file handler is operating in a different way to the others, perhaps as an intermediate read and decode stage.

In my case it is a Windows 11 client and the share is hosted on Windows Server 2025.

[riyasy]

@ittroll , Does this issue happen only with Network share?
Is Fly able to delete all type of files in normal folders?

[ittroll]

Delete works fine for all file types on a local folder. I can just keep hitting delete until there is nothing left.

I think the difference is the Recycle Bin, which is typically disabled for a network share. If I compare with Picasa, it asks for confirmation when deleting from a network share, presumably because it has detected that the Recycling Bin is not available.

With Fly it doesn't matter if confirm is enabled or disabled, the delete operation fails on a network share. So if the delete method you are using requires the Recycle Bin that would explain the error. Although this doesn't explain why I can delete ARW files from the same share.

[riyasy]

Currently, I don't have means to test with a network share.. Unless it is blocking for you, I shall keep this bug on hold for some weeks.

[ittroll]

It is not a problem for me as ordinarily I am working with local files. However, if you did want to test, you can recreate the issue by connecting to the administrative drive shares of your own machine. So use Explorer to browse to \\computername\c$ (or another drive if preferred).

[riyasy]

However, if you did want to test, you can recreate the issue by connecting to the administrative drive shares of your own machine. So use Explorer to browse to \computername\c$ (or another drive if preferred).

Thanks. I could replicate this. Very strange bug. The arw file is not locked, but jpeg locked when accessed over UNC path syntax. For arw and jpeg I use the same (WIC - windows imaging component + Win2d) code to load.

Seems a windows internal issue.

One option would be to load file into memory before trying to decode using WIC which would free the actual file (currently file path is given as input to WIC) . But this would be a overhead on performance and memory just to handle delete over UNC path.
Need to analyze the best way.

[riyasy]

This bug happens only in the WinRT modern APIs (StorageFile). Seems working with classic IO APIs of .net.

@Aemony @ittroll , Can you please check with this verison?

https://drive.google.com/file/d/1ifM-KJuJay1Bp_W1RQctplLFTLx2N6sz/view?usp=sharing

[ittroll]

Yep, that is working fine against my Windows Server. All image file types are deleted without error.
Is there any disadvantage to using this classic API?