They have date all the way to the present, so they were being created all along
I spot-checked a few, and they seem to be images that our users send through file upload. How did they end up in the \bin folder?
You likely want to review which plugins openfire has installed.
How do you envision that? Like, that I go through the list of plugins and admire their titles?
Like review which plugins are installed, see if any of them are not what you intended, see if any of them could explain why those files ended up in bin.
Seriously? a Person is dedicating time from his life to try and help you for free and you think that is a good idea to answer with sarcasm?
I am afraid I do not possess technical competency that could allow me to connect plugin titles with the file locations on disk.
Have you tried inspecting the files? Are they binaries? Plain text? Do their modification dates relate to activity in the logs? Do they stop appearing if you remove certain plugins? Try searching through the log files for the names of a couple of them, maybe that’ll turn up something.
Can you just list out the titles then?
As I had indicated in the OP,
Ah, I missed that. In that case, then it’s most likely that this is caused by the HTTP File Upload plugin. This plugin offers file-sharing functionality. People upload a file to Openfire’s server, where other people can download it. Those are the files that you’re seeing, I suspect.
The plugin by default should store those files in a temporary directory. For some reason, that’s not happening on your server. You can configure the plugin to use a different directory. In the Admin Console, go to Server > Server Settings > Http File Upload Settings to do that (as shown below). Make sure that the openfire process has permission to read and write files to the directory that you’re configuring!
A-ha! For some reason, it was set to blank.
Can I set it to %TEMP% so as to keep it under the standard Windows user’s TEMP directory?
Or do I have to use an absolute physical path?
When that field is empty, it should use the system-provided temporary directory. For some reason, it doesn’t do so for you.
I don’t think you can use environment variables like %TEMP%. You’ll probably have to provide a path.
This is an interesting notion. I wonder why would it not.
What circumstances may prevent it from working?
I don’t know. It is mostly governed by your Java installation. If I were to guess, it’s something with how your operating system and the version of Java that you use play together.
Were openfire tested on Windows, this probably could have been found out?
Well, being that windows users are the majority of Openfire users, either only you noticed this happening so far, or it only happened to you. But this is how the flow works, the Devs do their part developing(for free) and community members like you or me report whats not going right.
And what do you do?
I am just like you an Openfire admin. What i do is share my experience with newer users(being that i do run Openfire for many years already). And also reporting bugs.
Ah, so you are an unrelated 3d party, and no one authorized you to attack other users on behalf of the dev team? This is how you come across, from the history of your comments. Unlike developers, like Guus who are knowledgeable and helpful, you come across as rude and aggressive, and you have little if anything to contribute on the matters being risen here. And now I learn that you have nothing to do with the project as well. Hmm.
Intere
Interesting enough, there was and still is a subfolder
C:\Windows\Temp\xmppfileupload12275540806040148383
that contains very similarly named files. Even more interesting is the fact that their dates are interspersed with those of the files under the /bin/ directory. So it looks like Open fire does know to put some uploads under the TEMP folder, but other files end up under /bin/, and there is no pattern to that:
I’ve deleted the files under /bin/ but I did leave a note as to their date range, and they overlap.
Looks odd.
As per your suggestion above, I’ve populated the field as follows:
But still Open fire keeps creating files under /bin/
