File Download: Create destination path when not existing

[jacquesvandermerwe]

Is your feature request related to a problem? Please describe.

When we download files the destination folder has to exist before the file is downloaded. If we download multiple files where they happen to have the same name that will overwrite the file.

So the feature will be

box files:download <file_id> --destination=<path_that_does_not_exist>

That will download the file after the path was created if it doesn't exist.

Describe the solution you'd like

We use a bulk file and it would be good to be able to define the path and if the path does not exist, then the CLI should create the path

Describe alternatives you've considered

Create the complete folder structure before the download, but it adds a step that is cumbersome. Or we have to wrap the CLI commands in Powershell scripts

Additional context

There is a matching request for folder https://github.com/box/boxcli/issues/267

[mgrytsai]

Thanks Jacques for your proposal. I agree that if CLI resolve certain errors or missing parts, it should support it.

We'll definitely take a look at this use case and evaluate other situation where CLI can handle errors instead of user making extra step.

In term of timeline, I believe we'll pick this up in the second half of 2022.

[jacquesvandermerwe]

Thanks @mgrytsai just linked the counterpart for folders above. For reference https://github.com/box/boxcli/issues/267

That should be similar to the file path request

[mgrytsai]

Thanks. For internal reference, I created a ticket for SDK team to look at - SDK-2170

[mgrytsai]

Hi @jacquesvandermerwe ,

I'm trying to understand how the creation of destination path should work.

So far I can imagine two situations:

1. Single file download (e.g box files:download 917152365020 --destination=~/Desktop/1) If folder 1 doesn’t exist and CLI will just create it when the create-path flag is passed.
2. Bulk file download. In this case we provide a file with list of IDs and those files named the same. Currently, you can define only one destination path for your download command and if files named the same they will be overwritten.

Possible scenarios for bulk file download:

• What we can do is add new column destination to the bulk-file-csv input which will behave similarly to --destination param in single command. So for every file you could download to different locations.
• In addition to an individual destination, we can have a way to define file name for download. So in input CSV, you will provide ID and Destination, where destination is the full path to the downloaded file (e.g --destination=~/Desktop/1/myfile.csv)

In terms of interface, i think we need to expose a flag (e.g. --create-path=yes) to make sure user explicitly agrees to create folder if that doesn’t exist.

[jacquesvandermerwe]

Hi @mgrytsai

I think the create-path flag is ideal to allow the CLI to create the directories.

I'm split between the destination being a folder or file. I can see a use case for both.

For exporting files and renaming them on the destination, it can also be quite useful if the destination is a file name. Would to flags work? destination which drives the path and destination-filename which drives the files final name on the system? Both options can be available in single and bulk mode? In the absence of the destination-filename flag the files name is used as is.

[mgrytsai]

So we already have destination (file download) parameter. And we'll need destination-filename only file name ( e.g. myfile.txt) and then CLI with concatenate destination and destination-filename to get the final path to the file.

In the end, it could work like this for single and bulk action:

1. For folder download: box folder:download 917152365020 --destination=~/Desktop/1 --create-path=yes (destination-filename isn't available in this case - you can't rename folder at download)
2. For file download: box file:download 917152365020 --destination=~/Desktop/1 --create-path=yes --destination-filename=myfilename.txt

Above is my ideal state scenario, we'll need to explore if that technically possible and if we can use flags like that. At this moment, the behaviour is important for me.

[mwwoda]

Done under #393