En respuesta a un comentario de Marian Rainer-Harbach En este sentido, quería sugerir una respuesta que no es 100% firme, pero que refleja mi mayor familiaridad con el iPadOS adquirida en los últimos ocho meses. Creo que la respuesta a mi pregunta es un firme "no": las aplicaciones de iOS y iPadOS (incluida la aplicación Archivos) no puede crear archivos en un recurso compartido externo, excepto en casos muy circunscritos.¹
La cuestión aquí es con sandboxing de aplicaciones :
Por lo general, las aplicaciones están restringidas a acceder a los archivos dentro de su propia caja de arena, es decir, los archivos y directorios con los que se instalaron. Aparte de los archivos temporales de la caché, este es el sólo forma en que las aplicaciones pueden dirigirse a los archivos simplemente por el nombre .
Esto es algo que he aprendido utilizando aplicaciones como la Blink ssh/mosh shell Pythonista, iVim, Termius y otras aplicaciones que pueden proporcionar un acceso similar al de la shell de Unix u otras formas de especificar archivos por nombre de ruta. He complementado este aprendizaje por experiencia con algo de investigación en los documentos de Apple Developer, pero no pretendo ser un experto en el desarrollo de aplicaciones.
Así, las aplicaciones de iPadOS pueden acceder a los archivos contenidos en su directorio sandbox, como /private/var/mobile/Containers/Data/Application/$appID o sus subdirectorios, por nombre (en modo lectura-escritura si así lo desean), pero en el exterior ese directorio (en supercarpetas o hermanos), sólo tienen acceso por nombre a los recursos de componentes compartidos de forma segura (casi siempre sólo en modo de lectura), y generalmente tienen ninguna visibilidad en las cajas de arena de otras aplicaciones.
Aún así, las aplicaciones de iPadOS puede Obviamente, acceder a los archivos en otro lugar en al menos dos circunstancias:
- Un directorio de Documentos de iCloud creado para la aplicación; y
- Archivos compartidos con la aplicación a través de una hoja Share.
El directorio de iCloud es creado por el desarrollador de la aplicación utilizando CloudKit, y tiene una convención de nomenclatura específica: en el shell de Blink, por ejemplo, los archivos que puedo encontrar en la aplicación Files bajo Parpadeo de iCloud Drive están disponibles en el shell Blink bajo el enlace simbólico ~/iCloud .
Si leo ese enlace simbólico, puedo encontrar:
blink> ls -l iCloud
lrwxr-xr-x 1 mobile mobile 91 Mar 17 14:53 iCloud -> \
/private/var/mobile/Library/Mobile Documents\
/iCloud~com~carloscabanero~blinkshell/Documents
Así, las aplicaciones que utilizan CloudKit pueden "salir de su caja de arena", pero sólo hasta alcanzar lo que equivale a un segundo sandbox de iCloud, limitado a sus propios datos de Documentos de iCloud.
Por eso, desde la introducción de iPadOS (iOS > v13) y de la aplicación Files, algunas aplicaciones del iPad presentan una pantalla de apertura de archivos muy parecida a la de la aplicación Files; a través del UIDocumentBrowserViewController ofrecen al usuario la posibilidad de utilizar una interfaz similar a la de Finder para gestionar los archivos de una aplicación.
Sin embargo, por muy similares que parezcan ( así que similar, de hecho, que podría ser perdonado por pensar que era simplemente Files siendo utilizado como una aplicación de ayuda), hay una diferencia clave entre esto UIDocumentBrowserViewController y la aplicación Archivos: al pulsar iCloud Drive en la aplicación Archivos, encontrará un directorio que enumera todas las diversas aplicaciones compatibles con CloudKit que ha instalado, cada una de ellas como subdirectorios por los que puede navegar. Pero cuando se pulsa iCloud Drive en una aplicación utilizando el UIDocumentBrowserViewController se accede inmediatamente al subdirectorio Documentos de iCloud para esa aplicación ; no puedes "escapar" y mirar los documentos de otras aplicaciones de iCloud.
Compartir hojas son la otra forma en que las aplicaciones pueden acceder potencialmente a los archivos fuera de su caja de arena. Sin embargo, esto es iniciado por el usuario (a través de una operación de Compartir), y el objeto tipo archivo que la aplicación recibe es no accesible simplemente por el nombre de la ruta. No encontrarás una aplicación que incluya una lista de "Recientes" con los archivos compartidos a través de la hoja de Share, porque una vez que una aplicación ha perdido la referencia a un objeto de archivo que se le ha dado por handoff de la hoja de Share, ya no tiene forma de acceder a él de nuevo (a diferencia de los archivos en su propio sandbox, a los que puede acceder en cualquier momento por nombre).
Normalmente, eso significa que la aplicación que se está compartiendo no tiene la capacidad de crear un archivo - eso sería meterse en el sandbox de otra aplicación por su nombre y no está permitido.
(Hay una excepción para los "paquetes" -objetos en MacOS/iOS/iPadOS como aplicaciones que aparece en MacOS puedes hacer clic con el botón derecho en una aplicación en el Finder y elegir "Abrir paquete" para ver esto. Cuando los paquetes se comparten con los permisos adecuados, la aplicación compartida puede crear archivos dentro del paquete.
Si bien no responde completamente a todas mis preguntas, creo que estos antecedentes al menos explican el problema: excepto para los paquetes compartidos, las aplicaciones simplemente no pueden crear archivos en cualquier lugar, excepto dentro de su propia caja de arena. Mientras que la aplicación de archivos-como una utilidad del sistema-tiene un mayor acceso que otras aplicaciones de iPadOS/iOS para navegar por el árbol de archivos (incluyendo montajes de unidades de red), todavía no tiene el derecho de crear archivos fuera de su propia caja de arena por el nombre, que es lo que sería necesario para permitir la funcionalidad que estaba preguntando.
Mientras que el sandboxing de aplicaciones existe en MacOS -para todas las aplicaciones instaladas desde la tienda, y también para muchas otras aplicaciones, ya que Apple ha presionado a los desarrolladores para que implementen el sandboxing de aplicaciones en sus aplicaciones de MacOS- es una medida de seguridad siempre presente en iOS y iPadOS que, a diferencia de MacOS, no puede ser ignorado por los desarrolladores ordinarios, ni siquiera con la coöperación de los usuarios (suponiendo que no hayan hecho jailbreak a sus dispositivos).
El Finder es una aplicación de MacOS que no está sujeta a las reglas de sandboxing. La aplicación Archivos de iPadOS parece Finder, por lo que en su primera introducción era quizás razonable que los usuarios esperaran que trabajar como Finder, también. Pero como aplicación de iOS/iPadOS, aunque tenga acceso especial, Files tiene que seguir (la mayoría de) las reglas, es decir, no crear archivos en lugares aleatorios de la jerarquía del sistema de archivos.
¹ Esta discusión no se refiere realmente al almacenamiento Secure Enclave, que tiene su propio conjunto de requisitos, totalmente separado. Pero debería ser obvio que los conceptos de "almacenamiento seguro en enclave" y "almacenamiento en red" no pueden solaparse.
Por eso estoy publicando esta respuesta a mi propia pregunta, pero no la acepto a menos que reciba un número de votos positivos que sugieran que es, de hecho, la respuesta correcta; tal vez los comentaristas tengan correcciones o sugerencias.
También hay una excepción cuando una aplicación comparte un subdirectorio propio con otra aplicación; en el intérprete de comandos Blink, por ejemplo, se puede utilizar el comando open para dar, por ejemplo, acceso a un editor a los archivos de texto dentro de un subdirectorio de documentos de Blink. Pero incluso en este caso, esto sólo permite a la otra aplicación abrir y exportar a los archivos en el directorio extranjero; no obtiene acceso completo de lectura y escritura.
