I seriously considered not posting this because of the inconsistent results and I don't know how helpful this will be. This applies to version 3.0.3 with the August 31 build.
I select about a dozen files in a single directory for backup. I specify a name and destination for the zip file. Type is 'complete', format is 'zip'. I click on run and any of several possible things can result:
Sometimes everything runs as expected and I end up with a zip file in the correct destination containing all of the selected files.
Sometimes the program runs but only some of the selected files are archived. The missing files are not always the same.
Sometimes the program runs and after some of the selected files are processed, the progress window stops updating. Just clicking on the window results in a "not responding" message. Sometimes a window pops up asking if I want to end the program. "Yes". Do I want to send Microsoft a message? "No". Both the progress window and the main Toucan window close.
Sometimes nothing happens. Nothing runs.
I have had similar results on an XP machine as well as a Windows 7 machine.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
for the report. Could you try at the end of a backup that hasn't worked properly, before you close Toucan, to take a look in the data folder at the Includes.txt file. Are the missing files listed there?
I ran a backup several times. Each time I ran it, it ran until I got the "finished" message so there was no crash. For testing, I have selected 12 files. These are all text files and I am using the 'zip' selection. I checked three runs and in each case there were files missing from the resulting archive zip file.The missing files were not the same ones in each run. I looked at the includes.txt file after each run and in all cases there was only one file name listed. It was the last file that I was trying to archive and in all cases it was archived properly.
I did notice one thing. In the progress screen, occasionally the line,
"Creating file list, this may take some time."
is repeated a second time with nothing in between, not even a blank line.
The screen then proceeds normally and sometimes the duplication is repeated.
I don't have a lot of data on this but it seems that the number of duplicate pairs I get is the same as the number of missing files in the zip file.
Note that all of the above was done on a Win 7 machine.
I very much like the concept of your program and would like to see everything working well. If there are additional things I could try please let me know.
Bob
to check, are you adding the whole folder or the files individually? I am still trying to puzzle through this
I could not remember for sure so I repeated the test both ways. This time I used 3.0.3 release 5. In both cases (individual files and whole folder) everything seemed to work! I hate it when you can't duplicate a problem.
One thought occurred to me. I have used 7za, the command line version of 7z inside of a batch file to create a date stamped archive. Initially the line inside the batch file was something like:
7za a -tzip myarchive_%date%_%time% @myfilelist
a: add files
-tzip: use zip format
This worked as long as I ran the program in the afternoon! Evidently %time% inserts a blank when the hour is a single digit. 7za doesn't like that and does not behave as expected.
When I was trying to create archives with Toucan my destination was:
@drive@\myarchive_@date@_@time@
Is it possible that this might create the same sort of problem?
For anyone who is interested, the following three batchfile line work, assuming that 7za is in c:\7z. Note there are only three lines. This system may wrap because of line length.
set tmp_time=%time:~-11,2%%time:~-8,2%%time:~-5,2%
set tmp_time=%tmp_time: =0%
c:\7z\7za a -tzip myarchive_%date:~-4,4%-%date:~-10,2%-%date:~-7,2%-%tmp_time% @myfiles.txt
I have continued to try things with the backup function and have not been able to create the failures I had earlier. I have been using 3.0.3, build 6. I ran this in the morning to see if the single hour digit problem was there - evidently not.
Soooo ... either something got fixed or my testing was faulty.
am afraid I never did anything specific to fix this, but it is quite possible it got fixed when something else did, if it ever crops up again please say and thanks for the report