filecopy writer creating empty folder in same location as fmw workspace

Using FME Desktop Professional Edition 2017.1.2.0 on windows 32Bit

 

 

jdh wrote:

What are the settings on your path reader? Are you picking up the root feature as well?

The PATH reader source is the folder named base. Further PATH parameters below.

 

Path Filter: *

 

Allowed Path Type: DIRECTORY

 

Retrieve file properties: No

 

This will read in the folder contained in the base folder e.g. folder1 becomes the path_rootname.

 

I use the @Value(path_rootname)_@Value(_date)@Value(_time) in an attribute creator to create my new filecopy_dest_dataset. I then connect the path_windows attribute to the filecopy (file_source_dataset) and specify the filecopy parameters as below:

 

File Operation: MOVE

 

Overwrite existing file: Yes

 

Copy Source Folder: Yes

 

Copy Subfolders: Yes

 

 

If I don't introduce the attributecreator, the folder1 is moved to the new directory as folder1 with no problems. As soon as I introduce the attributeCreator, the folder1 is moved to the new directory as folder1_datetime with no problems, however, an empty folder named folder1_datetime is created in the same location as the .fmw workspace file.

 

 

Even if I try one reader (PATH) and attributecreator (New attribute: filecopy_dest_dataset) - Attribute Value: path_rootname) and the filecopy writer, the same problem occurs.

 

 

 

 

Hi @alex_pescud, it looks like you have found a bug. Thanks for bringing this to our attention. Hopefully @takashi's workaround works for you. I will post any updates to PR78234 here when they become avaiable.

 

-Liz

takashi wrote:

Hi @alex_pescud, I confirmed that the same symptom as yours appears with FME 2017.1.2.1. I think it's a defect of FME of newer versions. Hope someone from Safe takes a closer look at this.

As a workaround in the interim, the unexpected empty folder seems not to be created if you set the absolute path to the filecopy_dest_dataset. e.g. 

$(DestDataset_FILECOPY)/@Value(path_rootname)_@Value(_date)@Value(_time)

Thanks @takashi - your workaround solves the problem for now. Looks like this is a bug confirmed by @lizsanderson :)