We’re Still Here to Help (Even Over the Holidays!) - find out more here.
Forum Discussion
Solved
No errors in IFTTT applet log, but no file created in dropbox either
My IFTTT applets that create or appent to text files in dropbox have not been working reliably for months now. I was just looking at one applet's activity log and it shows that it has run dozens of ...
There really isn't anything that Dropbox can do to assist you. IFTTT would be the ones that created the interface between them and Dropbox, so only they can support it. Dropbox cannot provide support for third-party created apps or services.
If you had said that this just started happening, then I would suggest that it might be due to the Dropbox API v1 being shutdown recently (after being deprecated 15 months ago), and that any app or service that hadn't updated to use API v2 would fail to connect to Dropbox.
I do understand the "3rd Party" difficulties. What I was getting at is that IFTTT claims to be a "Premier Partner" with Dropbox (https://www.dropbox.com/business/app-integrations/ifttt). That leads me to believe the API is a collaboration between the two. I am not so inclined to go troubleshooting myself in such cases.
Hepcat: I spent my entire career in engineering support. Whenever someone came to me with a problem description as detailed as yours, I made it a point to thank them for taking the time to provide it. So you have my appreciation because understanding your problem helps me to understand similar issue I have.
In any case - I have seen comments that Dropbox has removed "public" folders. And I've seen IFTTT queries asking why IFTTT only uses public folders on Dropbox. I'm not sure what the status is relative to this, if it's been addressed, or a brand-new issue. I'm just trying to develop on my end something that works. Judging by the uptrend in Dropbox/IFTTT receipes, a lot more topics on both sides are going to show up. Hopefully these topics will be of the "how-to" variety, and not fouled up and broken API between the two.
Hi Jrtinz,
Thanks. I have finally gotten a work-around up and running and just had my first successfully pair of triggering events. Basically, since the handling of file name conflicts is inconsistent, even among the same services (e.g. the triggers "Life360: first person arrives" and "Life360:last person leaves" handle file name conflicts differently - the former does not create a dropbox text file and the latter creates a dropbox text file with an added string to make its name unique), I added a step to my folder action to delete the file at the end of the script. Sure, that's probably how I should have done it in the beginning, but until recently, I didn't know the shell tricks to safely handle spaces in the path/file name.
Now I'm left with the initial issue, that caused me to have to deal with this behavior in the first place: IFTTT added a colon to its datetime string that I was using in the file names. This caused syncing and other file issues (e.g. I couldn't edit a file with a colon in its name in text edit). So I had taken out the datetime string from the file name and encountered this inconsistent file name conflict issue.
I have a number of files that the applet created that have colons in the name, as evident from the dropbox web interface and from doing `ls` on the command line. The Finder displays the file names with a forward slash in place of the colon.
I think I could probably figure out a way to safely handle these files programmatically, but the issue remains that certain apps (e.g. Text Edit) are buggy when it comes to handling files with colons in their name.
