I see a variation on what you've described:
Symptom occurs even without field storage set to secure external.
i.e. when going down your list of steps to reproduce, when I get to step 4, I encounter these two symptoms:
a) I see the following error message:
"Untitled.pdf could not be created on this disk. Use a different name, make more room on the disk, unlock it or use a different disk"
b) Grepping the lsof output for "Untitled" shows the file as in use by FileMaker.
The pdf file seems to remain in a locked state until I create a new record in the test DB. It was not necessary for me to add another file to the field on a different record - simply creating a new empty record released the file.
A few other actions I tried did not release the file:
- changing records
- changing mode (to layout and back)
- opening define databases
Would a "commit record" help here?
You're right, standard containers seem to have the same effect. In my test DB, I still need to modify the container field on another record to release the original file (or something; I'm not sure what finally releases it, but simply creating a new record doesn't in the DB).
Strangely, a file added to the container via drag-and-drop, rather than Insert File, is not locked.
Unfortunately, no. Or at least, not in my test DB.
1) Commit Record did not help
2) I also tried a Set Field, setting the container field to its own contents -- also didn't work.
[ FMPA 12.0v2, OSX 10.6.8 ]
It sounds like the error both you and Steve are reporting isn't really with the container object but with the file on the desktop still being in use by FileMaker after FM wrote it. Is that your understanding of the error being reported?
If so, it seems that FM's under-the-hood processes are failing to recognize that it's done with that location. Sounds like something the FM engineers will have to fix.
Not quite. It's that the file on the desktop is in use after being inserted into a container field, not after FileMaker writes it. Other files, whether created by FileMaker or not, will also still be in use after being inserted into the container. It's just that this bug reared it's head in a script that saved a PDF and then stored it in a container.
But yes, it does appear that it's an issue for the FMI engineers.
Bug Report Time.
Not what the FM team wants immediately after a new release, but that's life in the software jungle.
Reminds me of releasing runtime upgrades....