If you go to the properties of any of our electronic files, the file path will show the file with the correct file extension as part of th name. (0000AB1.xls). If you go to the file path on the server for the electronic file, the extension is not saved. I have check and file extensions are not being hidden on the server. I appears that LF is just not naming them that way.
Question
Question
File extension is not saved for electronic files on the server
Replies
I had a conversation about this with an LF engineer at Empower a few years back. If I remember correctly the extension is saved in the repository database.
This is correct. The extension is stored in the repository database.
I don't like that at all. If I lose the database I don't even know what program to use to open an electronic file. Makes the backups of the images and electronic files almost worthless if there are no file extensions on the server.
Laserfiche repositories file volume and database backups are both necessary for recovery. See:
- Repository Backup & Recovery
- Repository Backup Scope
- Designing a Laserfiche 10 Backup and Recovery Plan
- Note: Valid for Laserfiche 11 as well
SQL databases are a core data source for nearly all Laserfiche applications. Any Laserfiche backup and recovery plan must include robust means of backing up and recovering the Laserfiche databases in addition to the file volumes.
One could nitpick many arbitrary details over what's stored in the repository database vs repository volumes, but those are ultimately two halves of a comprehensive data construct that relies on both being present.
If you have concerns around the implications of "losing the database", we would strongly suggest looking into leading practices to reduce the odds and risk of that scenario.
These include things like using SQL Server Full Recovery mode with frequent backups, regularly transferring database backups to a secure location, maintaining offline/off-site/immutable copies of backups that would survive a ransomware attack, etc.
I think it used to be the case that the files on disk had the extension. Maybe this changed around version 8 or 9, so that the value was only stored one place - i.e. just the database. And it seems like we did not update the web client to reflect that change.