All, I got some feedback from a customer I am working with. It seems to be a valid complaint. Maybe someone should take a look to resolve this in future releases.
Ok, Steve. Maybe you can tell me an easy way around this, because it’s annoying as hell. Really? A version delta of .0.0.0.1 prevents import? There has to be a way to tell WFA to just shut up and do what it’s told. I’m not upgrading WFA every time I want to look at some sample code.
Getting WFA to just 'shut up and do what it's told' might lead to worse implications than just a frustrating failure in importing a .dar file. WFA doesn't support backward compatibility for importing .dar files i.e. you can't import a .dar file created on a newer WFA version into a WFA of an older version.
In this particular case the user has created a .dar from WFA version 2.1(new) and then trying to import it to WFA2.1RC1 ( older ). This is not supported.
To solve this, the best way is to upgrade old WFA 2.1RC1 to WFA2.1 and then try to import this .dar. The user can take a backup on then 2.1RC1 and then restore it on to the newly installed WFA2.1 . After this all his imports will succeed.
WFA2.1 GA is already available and had some important fixes gone in from 2.1RC1 version. So its definitely better to upgrade.
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
On the subject of Exports - I have 2 builds (UAT and PROD) - both are on identical versions on code - 220.127.116.111.2-11275. On one when I export a command it is in dar format, while the other one is in zip format. Which means I cannot export/import between the environments - anyone seen this before?
Thanks Mike - although this was within the same browser windows, just different tabs the export file type was different - I renamed the zip file to dar and the import to the PROD system worked like a charm. Thanks again.
The problem is IE's MIME Type detection logic is 'buggy'. You have to specify a mime-type it doesn't know or it may decide not to trust it and mangle it, depending on the content of the first 256 bytes of the stream, how the zip compresses etc. To override the behavior there are different mime-type's that need to be set on the jboss server, something like application/netapp-wfa-dar would do it. See this post: https://communities.netapp.com/message/119878#119878. It looks like WFA 2.2 (in beta) has this updated so shouldn't see the problem in future.