Include timestamp and userid in export file name

[Niveshkrishna]

It would be interesting to add userid and timestamp to exported filename. This will give clarity to users when the file was exported and for which account.

I see that we already have this behavior with occ user:export command, where export file name has both userid and timestamp. Is there any reason why this is not replicated with frontend export job?

[Pytal]

This was done to reduce complexity iirc

As you export your own data from the web UI then at least within a user's own files there is no confusion to whose export it is

The date timestamp is also aleady available in files

[Niveshkrishna]

@Pytal This feature would actually be useful when users downloads the exported file to desktop for backup purpose. User can run export job once a month (from multiple accounts) and store it locally. By including userid and timestamp it will be clear for user when the export was performed and to what user.

[Pytal]

For that use case the occ command + scp to your desktop seems ideal, would that work @Niveshkrishna?

[Niveshkrishna]

@Pytal We want to offer this feature to all users in our NC instance, so manual occ + scp would not work in this case.

[Pytal]

Any thoughts on this @come-nc?

[Niveshkrishna]

@Pytal We started working on this issue for solving our use case. Let me know if you want me to create a PR here with this feature.

This is still in draft, as we are testing and evaluating for any bugs

Murena-SAS#1

[come-nc]

1. You are hardcoding Exports folder name, which has way more chance of being in use than our current archive name with custom extension.
2. Exports are stacking with your solution, eating up a lot of space if people export several times. This can be mitigated by quota because currently export is counted for quota, but original plan was to not count it for quota, which is part of why is has a fixed name. But anyway even with quota you may not want all your users to fill it with exports.
3. I do not really understand what usecase you are trying to solve. Instance or account exported is not ambiguous, it is the instance and account into which the file is existing. Date of export is the date of last modification of the file which is shown in the UI. When downloading the user can name it as they wish.
4. Your implementation is actually excluding from export any folder named Exports anywhere in the tree I think?

[Niveshkrishna]

@come-nc Thank for your review.

1. You are hardcoding Exports folder name, which has way more chance of being in use than our current archive name with custom extension.

Yes, it made more sense to export the files into a specific folder rather than user's root folder. As we are creating multiple export files

2. Exports are stacking with your solution, eating up a lot of space if people export several times. This can be mitigated by quota because currently export is counted for quota, but original plan was to not count it for quota, which is part of why is has a fixed name. But anyway even with quota you may not want all your users to fill it with exports.

I agree that this way exports take up space when frequently exported. We have two options, we can give auto-pruning setting to user to only retain latest 3 exports or we could warn the user about existing export. The reason why we feel using a constant name is a bad idea because:

• It overwrites the existing export (which user has not downloaded locally and could contain info)
• Does not maintain at what time date the export was taken
• When multiple users (family) download their exports, we don't know which export file is of which user. Adding userid becomes essential. Or when same user has two accounts and wants to download them locally.

3. I do not really understand what usecase you are trying to solve. Instance or account exported is not ambiguous, it is the instance and account into which the file is existing. Date of export is the date of last modification of the file which is shown in the UI. When downloading the user can name it as they wish.

I do understand that users have the option to name the file while downloading, but it is better UX if we explicitly provide them with all relevant info in the filename itself. This could especially be useful when migrating from one NC instance to other.. In fact we only wanted to add a .zip extension to file, but later we discovered that it made more sense to include uid and timestamp in name. .zip is needed in most OS, so that correct application is used to open/extract it

4. Your implementation is actually excluding from export any folder named `Exports` anywhere in the tree I think?

Thanks for pointing this out. I have corrected this.

I appreciate your feedback and would be happy to discuss more about it

[svenb1234]

1. You are hardcoding Exports folder name, which has way more chance of being in use than our current archive name with custom extension.

While hardcoding the folder name is not a good idea, not exporting to the user's root folder is a very sensible thing to do because you cannot exclude single files from syncing. Hence the desktop client will try to sync the exported file as soon as it can. There is no way to stop it but to pause syncing completely. Moving the exported file to some desktop should not be forced on the user.