Path reader not reading zips correctly?

hkingsbury wrote:

It could be that you're using the wrong slash.... try a backslash ('\\') in your glob pattern as you're reading a directory not a URL

Cheers Hamish. I've always read that forward slashes are better than back, but it's worth a try I guess! Wouldn't explain why this worked before though?

 

 

hkingsbury wrote:

It could be that you're using the wrong slash.... try a backslash ('\\') in your glob pattern as you're reading a directory not a URL

Error still occurs with a backslash, including if I escape it.

 

 

pallegama wrote:

Usually the path of the temporary unzipped location should be like below.

Desktop: Opening the PATH Reader on folder 'C:\\Users\\PRIYAN~1\\AppData\\Local\\Temp\\data_1.zip_1509582811289_2260'

 

Server: Opening the PATH Reader on folder 'C:\\WINDOWS\\TEMP\\fmeengines\\1SAUDSK2_Engine1\\FME_TempFileStore_1509582728242_10380\\data_1.zip_1509582728242_10380'

 

 

Since the path shown in your FME Server log has .zip at the end, it reads the location as a file instead of a folder. Could you please provide the complete translation logs on FME Server and FME Desktop to investigate the issue further. Furthermore, the folder structure of the source zip file would be helpful to understand why the path appends .zip.

Hi @chrisw84,

 

 

Probing into the issue I notified that this issue is due to limitation of file path length.

 

However, it seems to be FME 2017 handles this better than FME 2016.

 

 

The maximum character limit of a file path (including file name) is 260 characters in Windows API. Therefore, the folder path limit is 248 characters (12 characters less than maximum limit).

 

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

 

 

In FME, it appends a number at the end of <file name>.zip to create the folder name where it store temporary zipped file. It seems to be FME 2016 is truncating the appended number if the folder path hits a limit (I am not sure exactly what is the limit applied by FME) closer to Windows API limit. This leaves the folder name ending with .zip and creates the problem by identifying it as a file name instead of a folder name.

 

 

Since it is difficult to control the source file name in dynamic workflows, the best workaround for this is shortening the Temp folder path.

 

This can be done by setting the FME_TEMP system variable as depicted in the attached image.

 

Please re-start the server to set the new location after setting the FME_TEMP variable.

 

Hope this helps to solve the issue.