I develop an extension that adds another drive to JLab’s file system. It shows up as a separate file system similar to how the GitHub extension works. I’ve noticed however that it’s not possible to copy files between the external drive and the local (default) drive. I’ve tried with the context menu and with dragging; with dragging, a “no” icon appears over the drag image, implying it is not possible.
Should this work? Or is this by design?
I think this is not possible, but there probably is a workaround.
Technically, how would you imagine this working? The simplest way would be to request the file from one drive and save it to the other (the equivalent would be opening the file then “save as” to the other drive). Of course, this means the file has to make a round trip through the browser, which may be inefficient.
It would probably be better to have some way to transfer directly between the two drives without involving the browser.
I have used the “download”… “upload” workaround and it’s fine for the time being, but yes: it would be more intuitive to be able to transfer the files.
Unfortunately, as I’m sure you’re thinking as well, the variety of drives and their implementations make a generic abstraction difficult: I know for example that the GitHub drive can operate purely clientside (if not using an access token, I believe), meaning all requests would have to go through the browser anyways.
Yet, perhaps the solution can be to allow drives to opt in to this functionality (with the incentive that the drive feels like it works “better” when such functionality is either implemented or its impossibility is warned about.) Perhaps instead of buffering the file in the browser, in the event of a cross-drive transfer, a file’s download URL could be passed to the new drive on a “copy” operation (perhaps the name/type of the drive can additionally be an option to “copy” to further differentiate the cases.) The download URL can then be handled clientside (by requesting the download to a bytestream) or could be passed to a server handler. The server handler can then make the HTTP request itself, removing the browser from the equation.
This solution would also scale nicely to instances where the download URL is really a proxy endpoint within the Jupyter server; in that case, the server can loop back to itself, calling the proxy endpoint, which does the complex work of requesting the remote data source. To prevent unnecessary buffering in something like the JupyterHub proxy, some work could be done (if it doesn’t already exist) to automatically route requests back to the user’s server on the loopback device.
I like that idea. Would you open an issue in JupyterLab for implementing such a copy function?
There is even a long-standing TODO in the codebase to implement what you are describing: https://github.com/jupyterlab/jupyterlab/blob/b3152c6baf61ae194c2f1bf34d1acc08ed400444/packages/services/src/contents/index.ts#L822-L824
My thinking had been that the browser would store the intermediate file in memory, but if you can come up with a workaround with download URLs, that would be very interesting.
I have filed an issue: https://github.com/jupyterlab/jupyterlab/issues/7755 - I wasn’t sure how to format it, hopefully this is OK.