From 9a37141d291cbcccfc73476ff44807f0453f6820 Mon Sep 17 00:00:00 2001 From: Manav Rathi Date: Sat, 27 Apr 2024 20:38:49 +0530 Subject: [PATCH] Not yet sure how but desktop drag drops have the full path --- .../src/services/upload/uploadService.ts | 34 +++++++++++++------ 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/web/apps/photos/src/services/upload/uploadService.ts b/web/apps/photos/src/services/upload/uploadService.ts index 13aaf05b1..fd18ab4dd 100644 --- a/web/apps/photos/src/services/upload/uploadService.ts +++ b/web/apps/photos/src/services/upload/uploadService.ts @@ -431,9 +431,17 @@ export const uploader = async ( * * The file can be either a web * [File](https://developer.mozilla.org/en-US/docs/Web/API/File) or the absolute - * path to a file on desk. When and why, read on. + * path to a file on desk. * - * This code gets invoked in two contexts: + * tl;dr; There are three cases: + * + * 1. web / File + * 2. desktop / File + * 3. desktop / path + * + * For the when and why, read on. + * + * The code that accesses files (e.g. uplaads) gets invoked in two contexts: * * 1. web: the normal mode, when we're running in as a web app in the browser. * @@ -450,27 +458,31 @@ export const uploader = async ( * * In the desktop context, this can be either a File or a path. * - * 1. If the user provided us this file via some user interaction (say a drag + * 2. If the user provided us this file via some user interaction (say a drag * and a drop), this'll still be a File. * - * 2. However, when running in the desktop app we have the ability to access + * 3. However, when running in the desktop app we have the ability to access * absolute paths on the user's file system. For example, if the user asks us * to watch certain folders on their disk for changes, we'll be able to pick * up new images being added, and in such cases, the parameter here will be a * path. Another example is when resuming an previously interrupted upload - * we'll only have the path at hand in such cases, not the File object. * + * Case 2, when we're provided a path, is simple. We don't have a choice, since + * we cannot still programmatically construct a File object (we can construct it + * on the Node.js layer, but it can't then be transferred over the IPC + * boundary). So all our operations use the path itself. + * + * Case 3 involves a choice on a use-case basis, since (a) such File objects + * also have the full path (unlike the bona-fide web File objects that only have + * a relative path), and (b) neither File nor the path is a better choice that + * would be for all scenarios. + * * The advantage of the File object is that the browser has already read it into * memory for us. The disadvantage comes in the case where we need to * communicate with the native Node.js layer of our desktop app. Since this * communication happens over IPC, the File's contents need to be serialized and * copied, which is a bummer for large videos etc. - * - * So when we do have a path, we first try to see if we can perform IPC using - * the path itself (e.g. when generating thumbnails). Eventually, we'll need to - * read the file once when we need to encrypt and upload it, but if we're smart - * we can do all the rest of the IPC operations using the path itself, and for - * the read during upload using a streaming IPC mechanism. */ const readFileOrPath = async ( fileOrPath: File | string, @@ -1040,7 +1052,7 @@ const withThumbnail = async ( } else { // There isn't a normal scenario where this should happen. // Case 1, should've already worked, and the only known - // reason it'd have been skipped is for image files on + // reason it'd have been skipped is for image files on // Windows, but those should be less than 100 MB. // // So don't risk running out of memory for a case we don't