Some of my users have complained of getting the above error.
The program copies or moves multiple folderitems between disks. It uses MacFileOperationMBS.moveObject, .copyCopyObject and .moveObjectToTrash methods.
I know using MBS I can increase the number of open files, but my question is - what constitutes an open file in MacOS, and how does one close it?
Well, usually the destructor of something with a file stream, frees the file handle.
e.g. binary stream destructor.
The default limit is 250 files, I think.
Thanks Christian. What I hadn’t appreciated was that a folderItem instance was effectively an open file - regardless of whether you were doing anything with it. The program was effectively stopping at 250 folderItem instances.
I have reconfigured the program so that it now keeps the reference information to the folderItem (e.g. the nativePath) in scope. The folderItems are only instantiated when they are actually being used so the 250 file limit is no longer a limitation.
Did you check the open files list for your process in Activity Monitor to see what it said?
My understanding is that a FolderItem is not an open file. Maybe youve found a framework bug or there was something else going on.
A folderItem is not an open file.
BinaryStream, TextInputStream, TextOutputStream, Stdin, Stdout are.
As well as having a DynaPDFMBS object around with an open import file.
Or a FileMappingMBS object with open file mapping.
I’m not all the way to the bottom of the problem yet, but it seems to be related to using CGImageSourceMBS(folderItem) to get data about the contained photo - if there is one.
So yes, folderItem is not an open file - but examining its content does make it open (seems logical) even though the content only has scope within a constructor so it should close the file again afterwards (which it doesn’t seem to).