Dear ADNPlus --
I think 'half-done' is a matter for debate. If you've been following this really long thread on the IT department wanting to terminate FMPro, there are interesting points about different players, different focus, different goals and what happens with all of these to give a final result.
FMI development team made an interesting decision; that if you decided you wanted FileMaker to manage the container data, then you really were ceding control of the stored file to FileMaker Pro/FileMaker Server.
With FMPro, there isn't much hassle over where the managed container are physically located, but since FMServer has automated backup schedules, the question of externally located files is a bit more complex. One decision at FMI was to say that if a container is managed, the data within it is essential to the database, and the FMServer schedule needs to back it up. Most people would agree that it is desireable to avoid reduplicating the container field contents multiple times just for backup purposes which could easily overwhelm drive space. So, FMI is incorporating hard links to the external files, and somehow keeps track of added/removed/modified container contents.
Hard links can only be on a drive physically connected to the machine in question; you just can't make one to a network drive or cloud drive. Thus, you can't host external container contents outside of the FMServer machine when using FMServer.
If you still need to maintain the container data on an external source, then you still can, with a container as reference. And, you must take the responsibility to back them up and prevent folks from moving them around. And, take responsibility for getting them uploaded to that source in a way that is not overly cumbersome for the users. Troi-File plug-in is great for this (but now you have to be able to deal with cross-platform programming). I work on a system that used it extensively. I'm glad to be able to no longer have to work on that segment of the code, but it has not been removed from the system. We just added managed containers as an option (and hope to do less support for the Troi-File method). SuperContainer also has a lot to contribute to this as well.
-- Drew Tenenholz
REALLY BAD IDEA!!!
Using an external mounted location for storage of FMS12 container files.
1. OS cannot use Hard Linking across drives. Every single backup will be a full copy of all container files.
Backup drive requirements are now 12X the single backup size, 7 Days + 4 Weeks + 1 Month.
2. Must be auto mounted on restart of computer.
3. Any change in path or mounting (change drive name or install a larger drive) and the files will be tagged as inaccessible. If you are using secure storage those files may be lost.
4. A 'Headless' server has no user account to authenticate and mount external drives. You have to know how to mount at the OS level (using the root account (not just an admin account) and the command line) and make it authenticate so that the FMS account can access the external location.
Internal location access:
Its basic security. Services are NOT allowed free access to the hard drive. FMS can only access locations approved for its users and groups.
>FMI development team made an interesting decision; that if you decided you wanted FileMaker to manage the container data, then you really were ceding control of the stored file to FileMaker Pro/FileMaker Server.
What's so interesting about it? It's a bad decision.
FileMaker Pro can retain the link/reference to the path and complain if it gets broken for any reason by displaying some question mark, or message on the database container.
There is nothing wrong with that and it is something easily understood by users of files acustomed to working in a file server environment.
FileMaker server only backs up FileMaker databases. This does not have to change.
Why sell the ability to use external storage sources when this is clearly not the case? Why would it work on a non-hosted database but it won't if the same database is hosted on a FileMaker server which is hooked to the same network directory?
When you host a database with a container set up to store to an external location (within the same network), FileMaker overrides that connection and stores the files in the FileMaker server directory. So what used to be a dedicated FileMaker server, now becomes a file server too.
This is not good in any way shape or form, rather, it's misleading. Why bother to suggest paths in the Container storage locations dialog box to begin with?
Not sure what you mean by really bad idea. It's just file link related to a record in the database. If it's broken, fine, so long as it sees it next time that the drive is mounted.