Accessing Zip filename....

[DataMystic Support]

Hi Brent,

It was never a bug, it was never designed to do this until we designed in the new feature.

I appreciate that this took longer than we all expected to roll out (due to a gigantic workload).

I will see what I can do for you.

[alnico]

I guess I assumed it was a bug because the combination of filters did not work together as expected.
Anyway, we seem to have a fix now

Any word on getting this version to me...or just extending upgrades for me for a short term?

Thanks for your help...I have waited a long time for this...sorry to be such a pest about it.

Brent

[DataMystic Support]

Check your email....

[alnico]

Hi,

I thought I had this working but I am not sure it is...
I can rename the filename...but when it writes the file to the new path...the file is corrupt. The byte size of the new file is different.

I am not sure if I have something setup wrong...like I said, I thought this was working for me.

AND the "Process inside compressed files" is unchecked.

|--Restrict to filenames matching perl pattern [\\assets\\.*-es\.zip]
| |
| |--Restrict to file name
| | |
| | +--Perl pattern [([^\\]*)-es(\.zip)] with [$1$$2]
| | Maximum text buffer size 4096
| |
| +--Output to file(s)
| Output folder: Z:\test\

Thanks,

Brent

[DataMystic Support]

Hi there,

What are you actually trying to do?

I duplicated your setup and it seems to work fine. Can you please include the entire export? - or better yet, upload your filter as an attachment.

I turned on Prompt On Replace to see what was happening and it looked fine as well, although it did prompt on the filename twice.

It replaced:
C:\aemail\New Text Document-es.zip
with
New Text Document.zip

although the output filename in the new folder was already set to New Text Document-es.zip.

The Restrict to file name filter only works as the very first step of a filter - not inside a restriction, because TextPipe starts creating the target file in the correct output location (drive/folder), to avoid having to move the file between volumes at a later point.

[alnico]

Dang

I figured it out...somehow my source files got overwritten when building the script in TP and TP when done processing maintained a lock on them so they were not being automatically refreshed by another process.

So, closing TP, removed the lock, deleted tmp files, then re-uploading the source files, then re-running the TP scripts...it now working...whew One has to be sooooo careful

However, I did notice too that when prompted for replacement that it finds the same filename twice...not sure why...should I be concerned? Any Idea?

Thanks for your help.

Brent

[DataMystic Support]

Hi Brent,

We'll look into the double-processing, sounds strange.

Which file is remaining locked? If you can send us a complete example (filter, test file) we'll try and reproduce it, it should not be happening.

[alnico]

Hi,

Attached is the filter I am using. The first part of the filter is where I am simply renaming pdf contained zip files and outputting them to a new folder.
I do not know how the pdf's initially got locked...but maybe when I was shifting filters around trying to get it to work...it locked them. But, they appear to be working now.

The double-processing is a mystery though

Thanks,

Brent

[DataMystic Support]

The double processing occurs because the containing Restrict to filenames matching filter acts like a new file - so you get a trigger for the file (outside the restriction) as well as an event for the file (inside the restriction).

Here's how I modified it - one restriction, and the new folder set inside the pattern too (subfolder gg).

Restrict to file name
|
+--Perl pattern [^(.*)\\([^\\]*)-es(\.zip)] with [$1$\\gg\\$2$$3$]
[ ] Match case
[ ] Whole words only
[ ] Case sensitive replace
[X] Prompt on replace
[ ] Skip prompt if identical
[ ] First only
[ ] Extract matches
Maximum text buffer size 4096
[X] Maximum match (greedy)
[ ] Allow comments
[ ] '.' matches newline
[ ] UTF-8 Support

[alnico]

ok...thanks for figuring it out.

Brent