Can it be that duplicateFileDocument does not close the inputStream and therefore keeps a lock on the actual file being duplicated?

We have a situation where files are not deleted in a nightly clean-up although the Mx objects are deleted. Even more: when running the mf which is called from the scheduled event that runs nightly the files are also not deleted. However, when making a local copy using a backup from the production environment and then running the mf they ARE deleted. When opening the local file (e.g. with MS Word) and then running the mf they are NOT deleted. So somehow the FileDocuments seem to be locked in production. The files are imported using the SFTP module from the app store and they are duplicated using the duplicateFileDocument action from CommunityCommons. The latter does not call a close on the InputStream after duplication. Can it be that that prevents a lock from being released?
2 answers

Edit 1: according to many resources the file is locked if not closed explicit until the next garbage collection. So it would be better if community commons closes all streams.

You test this by replacing the function duplicateFileDocument with this in the

public static Boolean duplicateFileDocument(IContext context, IMendixObject toClone, IMendixObject target) throws Exception
    if (toClone == null || target == null)
        throw new Exception("No file to clone or to clone into provided");

     MendixBoolean hasContents = (MendixBoolean) toClone.getMember(context, FileDocument.MemberNames.HasContents.toString());
     if (!hasContents.getValue(context))
         return false;

    InputStream inputStream = Core.getFileDocumentContent(context, toClone); 
    try {
        Core.storeFileDocumentContent(context, target, (String) toClone.getValue(context, system.proxies.FileDocument.MemberNames.Name.toString()),  inputStream);
    } finally {
    return true;

I was in the end able to test this and indeed seems to be in the inputstream.close. I'll file a ticket.