I just discovered that it seems in either 9.7.5 or 9.8.0 the output of the rename file task changed from having between the source and destination filenames to having .

I have at least one task that was renaming a set of files, reading them, and then writing them back with corrections (because of a vendor supplying XML in 1252 encoding with a header that says it's UTF8, and that at least sometimes has two hyphens between a zip code and the zip+4) by looping through the output of the rename task. I'm working on fixing it now. Although for some odd reason the error it's raising is that there are illegal characters in the path when it tries to write back to the original filename, whereas what I would have expected to happen is that it would have started writing empty files because I didn't set the read file task to fail if the file doesn't exist, so it's just not finding the file whose path is an empty string...so there may be more at work here.

Side note: on a quick search I didn't see this change included in the change log; I assume either it was supposed to be, or this is actually a bug and I'll have to change my logic back later...

The loop was taking the entire output as one row, which presumably means the output of the rename task also switched line endings. It also didn't seem to be splitting into fields on "BlankSpace" anymore at all - even after switching line endings I was only getting one column with the entire line in it. Rather than continue wrestling with it, I think I'm either going to loop on the list of source files and just mimic the rename operation in the "read file" target, or give up and use task ID references and string operations so that I can loop from 0 to the number of files renamed and use

{STRING(GetLineByRowNumber|{TASK(<ID>|Result.RenamedFilesSource)}|{LOOP(CurrentValueX)})}

which should hopefully be more resilient; I usually prefer to avoid absolute rather than relative task and job references, but I think in this case it's less likely to break again later that way.

The loop was taking the entire output as one row, which presumably means the output of the rename task also switched line endings. It also didn't seem to be splitting into fields on "BlankSpace" anymore at all - even after switching line endings I was only getting one column with the entire line in it. Rather than continue wrestling with it, I think I'm either going to loop on the list of source files and just mimic the rename operation in the "read file" target, or give up and use task ID references and string operations so that I can loop from 0 to the number of files renamed and use

{STRING(GetLineByRowNumber|{TASK(<ID>|Result.RenamedFilesSource)}|{LOOP(CurrentValueX)})}

which should hopefully be more resilient; I usually prefer to avoid absolute rather than relative task and job references, but I think in this case it's less likely to break again later that way.

Thanks for the information. If you still want to troubleshoot this, send us an email to support@visualcron.com and refer to this thread/any more information you found

---