HTTP File Upload plugin should delete files as said in documentation

[akrherz]

...Migrated from Ignite Jira OF-1459...

reported by @wrooot

Have only tested this on Windows, not sure what happens on other platforms. Plugin's readme states that files will be deleted from the temp folder on the server after Openfire is turned off or when server runs out of space. On Windows i have found location of temp folders (if running with a regular user: C:\Users\User\AppData\Local\Temp\xmppfileupload_number, if running as a service C:\Windows\Temp). In both running modes temp files are not deleted when Openfire is restarted. Haven't tested if Openfire will try to delete them when server runs out of space. But it seems that it was a presumption that OS will handle this on its own. Windows is often not deleting files in Temp folders for a long time or ever. So in this case server can run out of space and even in that case might not delete them automatically.

We should at least clarify the readme on that. Ideally there should be a mechanism for Openfire to clean these files.

[jazzl0ver]

It would be great to add the following options regarding files removal:

• delete a file right after a user has it downloaded
• clean up tmp folder after some definable time frame

[Fishbowler]

delete a file right after a user has it downloaded

Interesting concept.

• How should it behave in a multi-user chat?
• Would it ignore any concept of multiple devices? (i.e. delete after first access)

clean up tmp folder after some definable time frame

Like a cron? How should the system respond when a user clicks a link to a file that no longer exists?

[jazzl0ver]

@Fishbowler

1. For multi-user chats I don't think it's required
2. Yeah, looks like there's a "hole" in the multiple devices case. However, that might not be a problem at all. A user that downloaded the file, may send it to his other device by other means. Or the openfire admin just should not enable the auto-removal feature :)
3. Yeah, like a cron. I don't know if it's safe to delete the files by a cronjob or there's some DB clean up required. If a user clicks on the link that is no longer exists, he gets 404 error, nothing fancy