What is the function/method to get the full path, starting at the root, to a container file with external storage. I cannot find any such function in FMP, MBS, anywhere.
thanks,
Because there is no use for such a function. The typical use case for it would be to be able to find that file and do something with it directly from the file system.
Remote Container data are actual live FM files and need to be treated like live FM files: nothing and absolutely nothing except FM should be able to touch it.
For RC data that means that the only interaction with them should come through the container field that they belong to.
1 Like
Yes, there is a need for such a function!
Case in point -> I need the container file path to pass to an email program. It already works in production (read only, of course), but is error prone since it falls in the user's lap (as is often the case) to manually figure out the path.
Since there is no way to get that path, I'll have to Base64-encode multiple FMP container files (separated by some UUID, etc.) and POST them to a service.
Thanks FileMaker.
Thanks,
Nope, to add it as an attachment you need to ask FM for it through the container, not from the hard disk.
The RC feature is NOT a document management feature, it's a backend FMS storage and backup efficiency feature. For all intents and purposes you have to treat the container field as if the file is embedded and not stored externally.
If you don't you're putting your solution (and things like your backups at risk).
If you want document mgmt features then just integrate with with a system that does that.
2 Likes
I've been using paths to containers for years with zero problems. It's just read only, Wim. Come on. I've done many, many, many tests. I had asked you before to come up with a scenario where this would fail, but you never identified one.
IAC, I'm going to change the code to base64-encode the container files and POST them rather than using file paths.
Absence of evidence is not evidence of absence. People have been driving around without insurance for years without getting into an accident too.
Read-only can still cause issues if you have no control over whether the mechanism may try to lock the file or even the folder it is in, or whether some other user is in the process of doing something to that field and FMS is in the process of writing to its RC storage.
The principle is simple: RC data is not ours to touch, only FMS should. And we should interact with container data through the container field only. Anything else is an added risk.
Whether you are ok with that risk or not is something to decide individually. But in this case, make sure the client knows that you are adding risk by using a feature in a way it is not meant to be used.
2 Likes
As I said above, I'm changing the code to encode all the container files instead of using disk paths. That will be more REST-like also.
Is this a hosted file?
Do you need more than GetAsText() gives you?
Yes - GetAsText() only returns the file name, not the full path starting at "/". In any case, as I noted above several times, I've re-architected the send mail service from FileMaker to use Base64 rather than file paths.
Thanks,
There is a difference between external storage and storing only a link to a file.
Store only a link to a file in a container and you can get the file path from FileMaker Pro.
Store a file, and not its link, in a container, regardless if external storage is used or not, and FileMaker Pro will not give you a path no matter the technique. Doing otherwise for external storage would be a security issue, especially on a server.
View a container's external storage as an extension of FileMaker just like Wim suggests. Mucking about in the container's file system can put FileMaker container data at risk and also circumvents many FileMaker security settings. There is really no safe use case to having access to a file's path.
You may want to consider an alternative. You could use the data file script steps to create and manage your own file storage system. You could then insert only a link to these files in the container fields. Remember, however, that the server is limited as to where it can create, manipulate and read files.
1 Like
Problems encountered with file references are common. Example: a file is moved or renamed, breaking the file reference. The problem is exacerbated by the time it takes for the issue to declare itself, especially with moves and deletions.
Developers may say referenced files can only be read. Problem is… how is this behaviour guaranteed? File system privileges could do it… but we're back to falls in the user's lap and error prone.
(removed.)
Thank you for this question. I see you found a satisfactory resolution early on but I appreciate that it lead to the sharing of a few bits of information useful for everyone. 
2 Likes
It's a lively bunch! 