That's an implementation detail in the IFS Cloud File Storage service that you should not care about, because it’s the service that decided how to store its data.

FYI, the file name looks to be Base64 encoded, possibly to overcome problems with characters that are not allowed in a file system. When it comes to Docman, which is probably the biggest use of File Storage, it's not a problem since we already make sure of this, but File Storage is a generic storage service and need to support any file with any name that gets thrown at it.

If you want to see for yourself what the file name "really" is, you can run it through a Base64 decoder, like this:

https://www.base64decode.org/

Hope this helps you understand this better.

CC @chanaka-shanil 

Thank you @Mathias Dahl for the explanation.

@Mathias Dahl This encryption was not happening when we were running on 23R2SU2, after the installation of SU3 it started to encrypt the files and store them in the file share. We are concerned about how this file storage service will access the encrypted and non-encrypted files from the file share.

For the sake of correctness, it's not encryption, it's encoding the file names, probably to avoid problems with certain characters.

It sounds strange to introduce this in an SU, but perhaps there were issues with what I just said and we had no choice than to encode the file names. 

PS. I'll try to get a comment on the latter from those who work with IFS Cloud File Storage.

 @Mathias Dahl explanation is correct. This fix was done to get around a few character encoding issues which was found in the FS for Remote and Cloud. The FS internally keeps track of the files with encoded names so any files prior to this change will continue to work without issue.

The file names are base64 encoded, so you can use base64 decode to get the file name, but as said, the actual file name is an implementation detail.