mac | pc external container naming issues

[happymac]

We have records with an external container, and sometimes the user will want to insert a new file into the container in place of the existing container file yet keep the same file name.  By design, Filemaker changes the file name to add an incremental suffix, so in the external container’s directory we see the original file and a new file with a suffix instead of deleting or overriding the original file.   so now we have two files, named originalimage.jpg and originalimage_1.jpg.  I understand WHY FileMaker does this ... it is sort of a fail safe to avoid a situation where a user accidentally uploads two images with the same name into two different records but since they technically different files, filemaker is trying to protect the original file from deletion. Problem is … in our case, we want to turn off this fail safe.  We have other systems in place that deal with duplicate file names, so if the user wants to upload a file with an identical name, we want to delete or overwrite the original file and not create a second file.

 

A good example is an image, where the user inserts an image into the container, then outside of FileMaker they edit that image so it is now a different file size with different attibutes.  Then the user inserts the newly edited file (but same filename) into the same record's container.   Currently the end result is that we end up with two files in the directory (one with a _1 suffix on the name), but we only want the new file to exist.

 

what I was originally thinking of doing was to first remove the existing (original) container (using set field to be "", or clear field, or cut) along with a goto field OR commit record and then inserting the new file.  but for some odd reason, this doesn’t seem to work.  The file names keep incrementing.

 

How can I clear the existing container data before I insert a new file into the container?

 

Thank you!

[johndwalton2012]

HappyMac,

    The issue here is two-fold.  The first issue is that the container field must be cleared and the record committed to fully erase the memory of the increment from the container field, and you seem to have a good grasp as to how to do that (e.g. Set Field using "", and the Commit Record).  The second issue is that the user must not be able to access the field directly at any time, as to do so would allow for this type of issue to continue, but to use any of the Insert... script steps you must have access to the field on the layout.  I would suggest that you lock the container field that is on the visible layout, and add the same container, unlocked this time, in the invisible portion of the layout so that you can keep the user from interacting directly with the field, but continue to allow for script access.

    Finally, I found when I was testing this that a Commit Record step was necessary both after setting the field to nothing, and after inserting the new file in the field for the directory contents to maintain consistency on inspection.

    Hope this helps.

 

John Walton

[Ocean West]

FileMaker tries to be helpful and keep only ONE copy of a file - even if you duplicate a record with container data on the back end only ONE copy of that attachment is stored. 

the best approach to ensure that each upload is unique and separate is to use secure attachments

or to add the recordID to the path relative path

but there is some caveats to aware of - if your path  of  file name / table name / and field name / and id exceeds i think over 256 characters and this is hosted on windows you may run in to issues especially if your ID is using Get ( UUID ) 

haven't ran in to this myself on mac but i know hosting companies who host on windows have experienced this issue. 

it is recommended you should not touch any files that reside in the external storage paths. - switching to secure storage will prevent that temptation.

 

[happymac]

thank you Ocean West for your suggestions, I appreciate your help.

In this case, we are updating the exact same record, and there are no file names that are the same.  we have a script that doesnt allow a duplicate name to exist before it inserts (using set field) into the container.  So the file naming incrementing (_1) is not a result of a duplicate file name.

Basically the user drags and drops the image into a "temporary" container field, and then we check for file naming issues.  If there are no issues, then the script continues with set field container to be temporary container and then at the end we clear (using set field "") the temporary container field.  the user doesn't have direct access to the container field in question, only this temporary container.  Also, the users do not have access to the directory where the files are being stored.   So, the user is inserting a new file in the same record and the goal is that the original file will be overwritten with this newer file keeping the same name.  but instead the new file is added as _1. 

because it is renaming the exact same record, I dont think this is a naming issue, but who knows???

Edited April 13, 2015 by happymac

[happymac]

johndwalton2012 - your suggestions are very helpful.  Thank you.

In testing, I tried exactly what are you suggesting ... to add a bunch of commit records ... and it doesn't seem to make a difference.  What's odd is the file seems to eventually get deleted, but it takes minutes to occur and obviously the new file is still being named with the increment (_1)

and ... we don't give the user access to the container field (just as you suggested) ... Basically the user drags and drops their image into a "temporary" container field, and then we check for file naming issues first.  If there are no issues, then the script continues with set field container = temporary container and then at the end we clear (using set field "") the temporary container field.  the user doesn't have direct access to the container field in question, only this temporary container.  Also, the users do not have access to the directory where the files are being stored.   so, the user is inserting a new file in the same record and the goal is that the original file will be overwritten with this newer file keeping the same name.  but instead the new file is added as _1. 

so the order of script steps ...

 

1) user drags and drops into a temporary container field, which has a script trigger that activates the script

 

2) goto field

 

3) commit record      // this was added to try and solve the problem we are seeing, the goal here is to clear the original file before we insert a new one.  it doesnt help

 

5) set container to be ""      //(using set field = "") this was added to try and solve the problem we are seeing, the goal here is to clear the original file before we insert a new one.  it doesnt help

 

4) set container to be temporary container      // this adds the new file with a problematic\ file name _1

 

5) goto field

 

6) commit record      // this was added to try and solve the problem we are seeing, the goal here is to clear the original file before we insert a new one.  it doesnt help

 

7) set temporary container to be blank (using set field = "")

 

it seems that adding the commit records has no bearing.  Also whether the container is on the layout or not seems to have no bearing as well.

Edited April 13, 2015 by happymac