For a new table we need users to be able to upload files to a folder. To protect the integrity of these files the folder rights are set in such a way that files can be added but not edited or deleted. If users want to change a file in a record we want them to simply upload a new file. This also allows us to keep a history of all the files ever used in a record while keeping all the original files.
When I try to upload a file using the gui I get an “access denied” error. The folder then contains a new empty file with the same filename as the original. It seems that the gui always creates an empty file first and then tries to edit it which is not allowed in this case.
Is there a way for the gui to simply copy the file to the upload folder with the correct filename in 1 step? Manually copying a file to the same destination in Windows works fine.
Best answer by Erik Brink
I’ve consider database file storage but I’m worried the database will grow in size beyond control. I don’t have any experience with it and I’ve seen reports to always use it cautiously. What’s your opinion?
For database file storage, could you predict the amount of records with a attached file to expect? You could use the MaxFileSize option from the SF to keep the memory footprint of the database in control.
After some more thinking couldn’t the gui reserve the file name more passively, skipping the step of creating an empty file first? You could have it check if a file exists first. Then if it does append some characters to that file name and only then save the file with its unique filename in 1 step. That would solve the issue with file and folder rights. I’m no expert on file systems and file management though and there could very well be a good reason to first create an empty file that I’m unaware of. :)
We choose this solution because first we save the records, where we need the filename/path already, and a little later we upload the file content to its definitive location. We have to allocate the filename before saving to be sure the saved record doesn't reference a total different file with the same name.
The chance it will happen this way is small, but we can't allow it to happen in production environments.
I hope you understand our architectural choices here a little better now.