Get File Exists () always returns 0 for files in temporary folder

v18 introduced the quite useful ‘Get File Exists’. It works as expected for files in the ‘Documents’ folder but always returns 0 for files in the temp folder.
Anyone made the same observation?

FMPA v18.0.3 on MacOs 10.14.6. File hosted on FMS v18.

If I remember correctly it is by design?

Couldn’t find any specifics in the documentation.

I don’t have FMP 18, but I implemented a FileExists() function (one line of code in Java) about five years ago for FMP. This approach works with any version of FMP 12 or greater.

I can even post the code here if you want.

You pass the directory or file and it returns True or False. Forget about the “FMP ‘Specs’”. Instead, using a micro-service approach with a standard File API, there is NO artificial FMP limitation of what directory or file you pass it (because FMP isn’t in the mix for this function). The file or directory either exists or it doesn’t and could be anywhere addressable via mapping or volume – local or on a different machine or wherever.

You can set up a micro-service to add this method to in less than 2 minutes. See the link here on this site:

FMPDUDE-VIDEO: Creating a micro-service in a couple minutes (with FMP example)


I would file it as a bug with Claris - if it is not documented it is a bug.

1 Like

Just want to double check if this is an error of mine or something others can reproduce.

Why waste your time filing a bug report for something FMI will possibly never fix or maybe never make the function work like you need it to (w/o artificial restrictions, if any).

Here’s my version. Took less time to create than filing a bug report. And it works not only from FMP but from any other HTTP-capable application.

Only one line of code in FMP, a single INSERT FROM URL, (and a single line of code in the micro-service) works from FMP 12 or greater (no maddening FMP “?” when FMP can’t give you an expected result or error message):

While I’m glad FMI finally got around to adding file functions in version, gulp, 18, I still wouldn’t use them if I had 18. Why? During a recent benchmark, the same logic in Java code running in a micro-service was about 400 times faster than FMP’s new “while()” function. Other FMP functions are also faster often much faster in a micro-service.


I consider to write my bug reports here in this forum. Much easier than with this SalesForce crap.
I then would make a screenshot and send it by fax to Claris Inc. :wink:


I was just saying that bug reports I took the time to file in the past were never even acknowledged by FMI let alone ever fixed.

Thus, for any FileMaker work, why not just skip the problem (another potential FMP bug) in the first place in a few minutes with a more general approach that isn’t limited to just FileMaker and runs much MUCH faster? (Often with a lot less code than would be required in FMP)

The beauty of a micro-service is that it is easy to create, it works anywhere, it works with any operating system, it works on any computer, it works at any location, and it works with virtually unlimited users. All for free . A micro-service is NOT a plug-in, so … FileMaker (1 FileMaker instance or 10,000+, one FMS instance or 10,000+) or no FileMaker…a micro-service is totally independent so you can use it with any HTTP-enabled application (an application that can issue HTTP verbs like GET, POST, etc. Terminal, Browser? No problem.). What’s not to love?! You Write and Control The Code ! (not some third party).

“A clever person solves a problem. A wise person avoids it.”
― Albert Einstein