Since this weekend, when I try to create a new app in Wit.ai by importing from a backup just saved from another app I get a blank error message and the new app receive only part of the information from the backup.
Here is the blank error message
Has anyone encoutered the same problem? Any suggestions on why it may be and how to solve it?
If you tamper with the original archive, do not add directory entries to the backup.
zip --no-dir-entries project.zip -r project
adding: project/actions.json (stored 0%)
adding: project/app.json (stored 0%)
adding: project/entities/intent.json (stored 0%)
adding: project/stories.json (stored 0%)
will work.
Adding the directory entry for entities
adding: project/entities/ (stored 0%)
seems to break the importer.
I kept receiving same error. In my case it had nothing to do with the content and/or formatting and/or encoding of any of *.json files.
Solution that works for me now is:
1) Export zip from any Wit.ai application (Even completely empty)
2) Copy all *.json files that are meant to be uploaded directly to this zip - overwrite or append files as needed
3) Import your app from a backup using this modified zip file
I had the exact problems. So if anyone else stumble upon this. Check that your bot is valid and has no empty bookmarks (first issue), recursive errors (had this as well) or similar.
I notice the same issue with the new wit.ai ui. So I just use the previous version of api for backup and restore
Related
We have a process in place built on Excel VBA that uploads a file to FTP Server. On the other side, our client downloads it. Very randomly, they complain that the file they received is blank (the file name is the same though). We then check at our end and see that the file that was uploaded was never blank. So here comes the problem: we're always arguing whether it was our error or theirs.
I figured that there might be a couple of reasons behind it but I have a few questions to ask before coming to conclusions:
If, say, the file was never uploaded (a possibility), what happens when the client runs a download process at their end? Can that download process generate a blank file with the same name as our output file? It sounds impossible to me but since the client is following up on this issue, I have to ask this silly question.
How does the mechanism work - what are the steps that happen on FTP server the moment my process completes uploading the file? I sometimes see that as soon as I upload the file, a 0kb file is created and then a second later (or less) the file with right size appears? Could it be possible that their process is running right before this actual file creation?
Thank you in advance for your help!
By default log rotate shifts file name's index on each rotation. I would like to keep names for old files. On each rotation: create new files + delete outdated.
Reason: every time I am rsycn those files with another sever, I have to download ALL file instead of simply downloading newly created ONE file and removing outdated ONE file.
Thanks
This web site and its users simply s#cks! This web site dedicated to newbie questions, which later will be replied by another group of newbies who will use google search to copy&paste reply (have no clue what they are saying) or by replying irrelevant clarification posts.
I am using cruisecontrol.net +msbuild. It has been working well for sometime and for the last two days I am getting this error. why is it trying to copy pagefile.sys? here is the errorlog. Thank you all in advance for your help.
Error message:
"[CDATA[Could not copy "C:\pagefile.sys" to
C:\CCNet\PublishedFiles\_PublishedWebsites\merp\roslyn\pagefile.sys".
Beginning retry 1 in 1000ms. The process cannot access the file 'C:\pagefile.sys' because it is being used by another process."
Perhaps some .target files have been accidentally edited in the .NET Framework directories, as it is said here. A sort of workaround I would prefer before reinstalling VS, would be changing the swap file disk in System Settings (if you have other logical/physical drives).
So we have a client that creates "training packages" and then uploads them via ftp to their website. They create the training packages in PowerPoint, and then use some program to convert them into html/swf files and package them within a folder. When they upload, they use Filezilla, and just transfer the entire folder over. The folder is uniquely named, uses no spaces or special characters.
These files have uploaded fine for about a year. Recently, they've run into a problem. Whenever they try to upload training package folder, they are immediately presented with the "This file already exists, do you want to overwrite?" message. Except... the folder they're moving is brand new, and the file it's asking to overwrite DOESN'T EXIST. When they choose "Overwrite" the file looks like it transfers, but the file size is wrong, and the training package doesn't work correctly.
This happens with every training package they try to upload. It's not just a badly outputted package. Also, it's always the same file that has the problem--it's the main "player" for the training package, and though it contains different content for every package, it is the same file name (cplayer.swf) every time.
Things they've tried without success:
-Re-uploading the file again by itself, and overwriting
-Deleting the "bad" file and re-uploading the single file - Get the overwrite message again, even though the file DOES NOT EXIST.
-Renaming the file on the server and re-uploading the single file - Get the overwrite message.
-Renaming the single file locally within the package and uploading/renaming it - Won't let us rename because the file already exists.
-Used another FTP client - Same results as above, so not a client specific problem.
-Used a different FTP login - Same results as above, so not a permissions problem.
Other things of note:
-The file is small--it's not a time out problem. Plus, all other files upload fine, and some are a lot larger.
-They've emailed this file to me, and I've uploaded it successfully.
I am completely at my wits end. Does anyone have any ideas where I can at least troubleshoot a little further?
Thanks for the non-help, the downvote, and the general lack of response on what was a pretty serious issue for me.
In case anyone else has a similar problem, here's what was going on:
Virus software (specifically Malware Bytes) was blocking THIS ONE SINGLE FILE. All I had to do was exclude the folder that contained the file.
I'm using Paperclip (2.3) to handle image uploads on a Rails 3.0.3 app running on Ubuntu. Paperclip is handling the uploads as advertised BUT the RackMultipart* files that are created in the application's /tmp folder persist -- that is, they simply accumulate rather than deleting themselves. I realize that I could use tmpreaper to delete old tmpfiles but I'd really like to find a more elegant (and scalable) solution.
I had a previous issue with temp files (i.e. RackMultipart* files) accumulating in the Rails app's root directory (instead of in /tmp). I resolved this by explicitly setting the temp path in my environment.rb file like so:
ENV['TMPDIR'] = Rails.root.join('tmp')
Is there another environment variable that needs to be set to make sure that the tempfiles are handled properly -- i.e. deleted once they've been saved in the model? I'm not sure if this is a problem with Paperclip or my Rails setup.
I've searched high and low but have made little progress on this. I'd be grateful for any leads.
Sincere thanks.
PS - I'm using currently using S3 for storage. This doesn't seem to be tied to the problem though -- I had the same problem when I was storing the files locally.
The TempFileReaper is the Rack middleware thought to handle this issue.
http://www.rubydoc.info/github/rack/rack/Rack/TempfileReaper
Including this line in the application.rb solves the problem:
config.middleware.use Rack::TempfileReaper
I don't know if this is anymore elegant but this is what I am doing after the file is saved"
tempfile = params[:file].tempfile.path
if File::exists?(tempfile)
File::delete(tempfile)
end
UPDATE: Problem should be resolved in rack-1.6.0.beta2. I see it's already being used in Rails 4.2.0.rc2.
Below workaround served me well for almost a year:
I've added this at the end of controller action that accepts file uploads:
Thread.new { GC.start }
This triggers Garbage Collection of unused Rack::Request objects which also deletes associated temp files. Note it doesn't sweep temp file of current request, but it does remove previous files, and prevents them from accumulating.