Windows File Transfer - Diff Between V9 and V11?

[laura_albrecht_automic]

Hi.  In the midst of consolidating 2 systems.  V9 into a V11 system.  Just found an issue where we have a file transfer doing a Windows to UNIX transfer.  In V9 they have *.DAT in the source filename and transfer it as *.dat.  The kicker is that the file actually IS an *.dat file on the source side, but in V9 it still picks up the file.  It's like it's not case sensitive.  Which makes sense, that is generally a UNIX thing.

But we migrated this file transfer to V11 and now suddenly the file transfer is failing with:

U00063069 Unable to convert filename, mask 'F:\qa\batch\sap\in\endopaladin\*.dat' does not match with filename 'F:\qa\batch\sap\in\endopaladin\Shire Reports_20171012000937.DAT'.

Obviously, the EASY answer is just to update the file transfer so that it has *.dat instead of *.DAT but I could swear that I remember something about this in the Release Notes or somewhere along the way.  Does anyone remember?  Is this something that was tightened up between V9 and V11?  I'm trying to find a reference in the HELP or Community but I haven't found anything yet.  I just want confirmation that there is a reason behind what we're seeing.

Hopefully someone has a better memory than I.  :-)  Thanks.

[Carsten Schmitz]

Hmmm ... I have read no such thing, and out of curiosity I just googled it extensively and could not find anything either.

I also just tried your filename (as "Shire Reports_20171012000937.DAT", verbatim) and copied it with a JOBF from one Windows machine to another using a V12.1 and V12 agents (I don't have access to a V11) and it worked fine, using the pattern "*.dat":

2017-12-08 10:29:11 - U00011124 Selection started with filter 'c:\redacted\*.dat' ... 2017-12-08 10:29:11 - U00011125   'c:\redacted\Shire Reports_20171012000937.DAT' 2017-12-08 10:29:11 - U00011126 Files selected: '1'. 2017-12-08 10:29:11 - U00011133 OK    '11' Bytes, '0' Records for file 'c:\redacted\Shire Reports_20171012000937.DAT'->'c:\windows\temp\Shire Reports_20171012000937.dat' transferred. Duration '00:00:00'. 2017-12-08 10:29:11 - U00011408 FT '175165128': FileTransfer completed.

(edit: The truly funky thing is that I used the "&1" placeholder for the wildcard part in the target file name, and as you can see, Automic even turned .DAT into .dat for no good reason at all on the target side ...  ;)  )

My gut feeling is, there is a different problem and the error message received from Automic is wrong. You might want to look into permissions, or whether f:\ is something special (as in, not a local drive or mapped CIFS share). In my experience, the error messages received especially in conjunction with JOBF on Windows are often plain missleading.

If you do confirm that this is indeed an issue of letter case after all, that would be a bug (but apparently only in V11), because while NTFS is case sensitive, the Windows API by definition is not (well, the whole story is that parts of Windows can be case sensitive, e.g. when you're using the old Windows Services for UNIX APIs, which had to be, because POSIX requires case sensitivity. But the Win32 API is by definition not case sensitive, so if confirmed, that would be incident-worthy IMHO).

Also, what an earth is an Endo Paladin? That sounds like the coolest AD&D thing ever ...  :D

[laura_albrecht_automic]

My memory is not great, so it's possible I'm half remembering something similar, but not quite applicable here.  Thanks for the feedback Carsten_Schmitz_7883 !

I'm going to do some additional testing.  Will post my findings here.

No idea what Endo Paladin is!  Haha.  Somehow I doubt it is as exciting as you are thinking.  :-)

[Carsten Schmitz]

Laura Albrecht said:

No idea what Endo Paladin is!  Haha.  Somehow I doubt it is as exciting as you are thinking.  :-)

It's either Paladin Labs, a pharmaceutical company recently aquired by Endo Corp (boring indeed), or the mystical inward-channeling Paladins who smite with the glowing shards of JOBF +3  :p

[laura_albrecht_automic]

I found FT_VERSION in UC_HOSTCHAR_DEFAULT.  If I set this to 1 - the file transfer works and picks up the file even though the case is different between the server (actual file) and file transfer (pattern to look for file).  

I can't find this setting in the HELP.  But it's working now.  :-)  

[Carsten Schmitz]

Hey,

I would still recommend to file an incident especially if you can replicate it by simply switching FT_VERSION. The reason being that FT_VERSION = 1 is reportedly rather bad for performance and heavily discouraged. At least that's what I am told in the Automic Health Checks.

BR,
Carsten

[laura_albrecht_automic]

Thanks Carsten_Schmitz_7883 .  Turns out changing this setting caused other problems, so we ended up changing it back anyway.  We have opened up a ticket.  Will let you know what we find.

[peter_grundler_automic]

Carsten Schmitz said:

Hey,

I would still recommend to file an incident especially if you can replicate it by simply switching FT_VERSION. The reason being that FT_VERSION = 1 is reportedly rather bad for performance and heavily discouraged. At least that's what I am told in the Automic Health Checks.

BR,
Carsten

Hi Carsten,

this parameter was introduced to change between the old (v8) and new file transfer protocol because some customers experienced issues after the upgrade.
If not specified, the new - enhanced and optimized - protocol is default.

As this parameter is already deprecated is should no longer be used (not sure if AE still supports it).

regards,
Peter