We have a task that 7zips a bunch of files from a network location to a subdir in that same network location. What's happening is that the 7z file is created and the filenames are added to the 7z, but each file in the 7z is 0 bytes.

Example - the task is made to 7zip the file in the \\mycompany\datafiles directory and then 7zip those and put the 7z file in \\mycompany\datafiles\archive directory. The 7z file is created but the files themselves are empty. The job is reported as successful and nothing seems to be written to the logfiles that point to an issue.

The task itself has a file mask for all txt files in the directory that match a modified date of 'all files older than the first of the current month'.

When I change the task to zip, it seems to work fine in that all the expected files are compressed into the zip file. When I first get visualcron to copy the files to it's local drive in a temp directory, it will compress the files correctly but I'm hoping to avoid having to do that simply due to the extra time. Creating the 7z file manually using the 7zip application works fine.

We've now tried this on v8.2.5 and the latest version.

Has anyone seen this before or run into the same problem? Any ideas where I can look or if I'm doing something wrong? I haven't exhaustively tested (i.e. turning off the file masks / dates), etc. but since a zip file works with the same thing, I haven't gone that yet.

I created a job that mirrors what you are doing using Date Modified < {DATEADD(Months|{DATEFORMAT(MM)}/01/{DATEFORMAT(yyyy)}|M/d/yyyy|-1|M/d/yyyy)} and 7zip worked fine. I am using v.8.5.1

Interesting. Although that particular date string returns Field 'Older than' value is an invalid date but that might be due to this server being on 8.2.5.

I feel that the date has nothing to do with it, it's just another data point. As mentioned, the same file mask and date works perfectly with a zip file just not 7zip.

Kind of wonder if this has something to do with having 7zip installed separately on the server as it's own application. Will have to take a look at that.

If you're doing the exact same type of operation, it's good to hear that it works. We'll keep looking here - in the meantime, open to any other ideas.

Interesting. Although that particular date string returns Field 'Older than' value is an invalid date but that might be due to this server being on 8.2.5.

I feel that the date has nothing to do with it, it's just another data point. As mentioned, the same file mask and date works perfectly with a zip file just not 7zip.

Kind of wonder if this has something to do with having 7zip installed separately on the server as it's own application. Will have to take a look at that.

If you're doing the exact same type of operation, it's good to hear that it works. We'll keep looking here - in the meantime, open to any other ideas.

Would you be able to try the latest beta build and see if you still get the same issue?
https://www.visualcron.c....aspx?g=posts&t=9617 

---

I shall and post back. Thanks!

Got it updated, still nothing on the compression. I also found and tried a server that has 7zip already installed on it.

I removed the file masks and date just to see and same thing. I *did* find that if that file that it's adding to the archive come *from* the network, then it's not compressing the files. However, if the files are coming from local, it will compress and write back to the correct directory.

Example: compression source is c:\myfiles\*.txt and destination is \\mycompany\datafiles\archive\file.7z

So it almost looks like a network issue except that zip doesn't do that.

Got it updated, still nothing on the compression. I also found and tried a server that has 7zip already installed on it.

I removed the file masks and date just to see and same thing. I *did* find that if that file that it's adding to the archive come *from* the network, then it's not compressing the files. However, if the files are coming from local, it will compress and write back to the correct directory.

Example: compression source is c:\myfiles\*.txt and destination is \\mycompany\datafiles\archive\file.7z

So it almost looks like a network issue except that zip doesn't do that.

Ok, can we move this troubleshooting to e-mail, please? Or the online chat would work too (you can just click the bottom right on the "Online" text, we're online most of the time). I will need some more information in terms of screenshots of your all your settings related to the problematic task(s).

So, mail us at support@visualcron.com or use the online chat function. Will post the result of the troubleshooting here as a reply when we're done for future reference/others who experience the same issue.

---

Sure, email works fine.

I'll continue to experiment more and post back any type of solution. For the moment, a valid workaround is to get the task to move the files to the server, compress, and copy the compressed file back.

Thought I would provide quick update with thanks to Michael. We still haven't tracked down the actual problem but I was able to look though some log files and saw that, when the task didn't work, it was server machine account that was trying to access the files, and not the actual user. When the zip task is used (instead of 7zip), it's the visualcron user account that's used.

I tried playing around with a number of different settings in the Credential manager none of which made a difference.

Then I tried mapping a network drive in Visualcron via the Network drives section. Without restarting the client, the job now works. If I remove the drive map and restart the client, the job fails. Then, adding the drive map back, the job works. The drive map doesn't have to be the same network path as the job that's trying to run, as long as it's got a drive map.

I'll keep chasing the issue as it seems a little strange and report back if anything is foun. For the moment though, this is seems to be a workable solution.

Thought I would provide quick update with thanks to Michael. We still haven't tracked down the actual problem but I was able to look though some log files and saw that, when the task didn't work, it was server machine account that was trying to access the files, and not the actual user. When the zip task is used (instead of 7zip), it's the visualcron user account that's used.

I tried playing around with a number of different settings in the Credential manager none of which made a difference.

Then I tried mapping a network drive in Visualcron via the Network drives section. Without restarting the client, the job now works. If I remove the drive map and restart the client, the job fails. Then, adding the drive map back, the job works. The drive map doesn't have to be the same network path as the job that's trying to run, as long as it's got a drive map.

I'll keep chasing the issue as it seems a little strange and report back if anything is foun. For the moment though, this is seems to be a workable solution.

Thanks for the information! I'm glad you managed to find a solution. We'll look into this a bit on our end as well. I still find it odd that I'm not able to reproduce your error, even without mapping the network drive.

---