Unable to save attachments when using filesystem that is backed by Azure-File storage class

[rmotapar]

Hi,
We are using spring-content-filesystem for storing attachments in our spring-boot based microservice. We are unable to save any new attachments when our app is deployed in Azure using Azure-File as the storage class in Openshift, . The call to FileSystemDeletableResource.getOutputStream() invokes FileUtils.touch(this.getFile()) method from apache-commons which in-turn calls Java's file.setLastModifiedTime() method. This method always returns false when using azure-file so we are seeing "Unable to set the last modification time for " error every time we try to save a new attachment.

This issue is specific to azure-file back-end filesystem and is not present in stores backed by NFS, local disk, clusterfs, etc. We did open a ticket with Azure and they were able to confirm that file.setLastModifiedTime has issues when using azure-file storage class. As a workaround, we have created our own implementation of FileSystemDeletableResource and replaced org.apache.commons.io.FileUtils.touch(this.getFile()) with java.nio.file.Files.createFile(this.getFile().toPath()). This solved the problem for us but we don't particularly like the way we have overridden this class (we had to inject a few other beans that eventually call our version of FileSystemDeletableResource).

We would like to instead use an official fix and would really appreciate any help you can provide.

Thanks!

[paulcwarren]

Hi @rmotapar, we can certainly try and do something. I always thought that touching the file at the point we do, at the point we create the output stream, was a bit dumb because it might not get written to. We should probably move that to when the file actually gets written to.

That said, to make sure we solved the problem I committed and pushed a direct replacement. I added a Files.createDirectories to make sure any intermediate directories get created. This wont be ab issue for you if you are using ContentStore but might be for users of Store.

That build was green. Would you mind testing it in situ to make sure we actually fixed the issue for you.

Thanks

[rmotapar]

Hi @rmotapar, we can certainly try and do something. I always thought that touching the file at the point we do, at the point we create the output stream, was a bit dumb because it might not get written to. We should probably move that to when the file actually gets written to.

That said, to make sure we solved the problem I committed and pushed a direct replacement. I added a Files.createDirectories to make sure any intermediate directories get created. This wont be ab issue for you if you are using ContentStore but might be for users of Store.

That build was green. Would you mind testing it in situ to make sure we actually fixed the issue for you.

Thanks

Thank you @paulcwarren . Unfortunately, we don't have the Azure environment up and running at this time. We used it for testing our application initially and had to shut it down once we were done. If we ever bring it back up again, I will test it in Azure.

Thanks again!

[paulcwarren]

OK. Well, I think this is a pretty harmless change with quite a lot of test coverage so we'll roll with it as-is.

Feel free to re-open this issue if turns out not to fix the issue.