macOS enforces so-called security scopes for all sandboxed applications, which means all applications distributed via the Apple App Store. This is a security feature. Since Photo Naminator is also distributed through the Apple App Store, it is hence a sandboxed application and the sandboxing contraints apply. One of these constraints is the security feature that allows such apps to only access folders and files in a user's file system to which access has explicitely been granted by the user in a macOS-controlled manner. This is done in either a File or Folder Picker dialog in the sandboxed application, or by dragging & dropping files or folders onto the application window, of by starting the app via "Open with..." in the Finder. For each file or folder handled this way, the system creates a security-scoped resource that is used to manage the constrained access to the file system by the application.
There are two main topics that need to be considered here that have a direct impact on your way of working with a sandboxed application:
Both cases are explained in more detail below:
Sandboxing file system resources distinguishes between files and folders, i.e. giving access to an individual file doesn't allow access to the folder containing the file. So while you may be able to read a file that was selected as input to an application, or potentially to change its content by writing content back, it does not mean that you could create a copy of that file in the same folder. Because that would change the folder itself. You may also not be allowed to move the file outside the folder -- again an alteration of the folder.
As long as you grant access to entire folders, e.g. by selecting an entire input folder (rather than individual files within that folder) in a File Picker dialog and/or you select and hence grant access to a specific output folder, you are all fine: things will work as expected and no specific action needs to be taken on your end. If you decide to only select individual files and depending on the operation you intend to perform, things can become more tricky. In those cases you need to sometimes grant access to an enclosing folder before an operation can be performed. The application will hint you at those specific situations and problems should they occur.
Hint:All goerke.tech applications will guide you accordingly in providing explicit access to a folder when needed. Also, folders you've once granted access to will be "bookmarked" so that you don't have to re-grant access at a later point in time again. The Settings section of these applications will allow you to review those folders for which granted access has been bookmarked; also, in that same Settings section, you can always revoke access rights at any point in time should you prefer to do so.
Hint: If you store the superset of files that you usually process, e.g. your photo files, all in a common place on your harddrive or an external device, you may grant access to a root folder of those folder structures once (e.g. access to .../Documents/AllMyPhotos) and this will get any access problem out of the way until you revoke the access right again.
Just to set things straight: Photo Naminator can handle an arbitrary number of files in a single run. But you may want to understand how to do this correctly (i.e. pass a folder, not individual files).
As explained above, macOS enforces so-called security scopes for all sandboxed applications and restricts how applications can access file system resources, i.e. files and folders. But as many other system resources the security-scoping has a limit, too, for the number of files and folders it can concurrently manage and to which it provides controlled access for an application. This limit is some magic, not officially documented number, but it appears to be around 2500 concurrently managed security scopes. If you try to exceed this limit by, for example, selecting 3000 files in a File Picker dialog, the system will unfortunately not warn you or even keep you from doing so. Instead, the files selected will all be passed to the respective application, but when trying to access the files, the application will fail with a "security scope" violation – the reason being exhausted system resources for that app to handle all those concurrent security scopes.
Unfortunately, at the point in time when your app usually runs into this issue, things will already be messed up: The app can not recover itself from those exhausted security scopes and the only way out is to quit the application and start over. Quitting an application will release all used system resources, including the (exhausted) security scopes. When you then restart the application, you get a fresh chance to not exceed the limit again.
To avoid this situation from happing silently in the background and you scratching your head over what's going on, Photo Naminator issues according warnings when selecting input files or dragging & dropping an exceedingly large number of individual files onto the app. Furthermore, should you accidentially select too many files in the File Picker of Photo Naminator, the app will warn you and not proceed processing. Instead, you will get asked to quit the application and start over: "Better safe than sorry".
No worries – Photo Naminator can handle an arbitrary number of input files in a single run. All you need to do is not selecting or dragging them individually, but instead selecting the (root) folder which contains all your input files and folders! Only a single security scope is needed for this folder you pass into Photo Naminator, and all files and folders contained within this folder can be accessed automatically as part of the folder's security scope. Photo Naminator does not impose any own limitation on the number of files.
