Hi,
first of all, thanks, its a great tool, been using it since ... ages, now I would like to help to make it a bit better![:)]( "Smile")
If you are using compression function and putting your stuff into a ZIP archive, the ZIP is being created in the temporary area (usually in users directory structures) and afterwards the copy process from temp directory to the final destination takes place.
However, if the destination directory doesn't exist, the archive is being created whatsoever in temp, and once compression is done, Reflector tries to move the file - but here it fails, as expected.
The compression is, of course, the longest running part of the whole backup, so I would expect it to not start at all, if the whole backup process has no chance to succeed. Once the ZIP file is successfully built, but the destination doesn't exist, Reflector deletes it from the temp, game over.
I would appreciate if Reflector could check the destination directory before starting the compression, so user doesn't have to wait XY minutes just to find out it was wasted time and he's on the start again.
It happens to me many times, when I make backups on external drive, that the drive sometimes gets assigned different volume letter from OS Windows.
User doesn't have to notice such change, so a quick pre-check would come in handy.![:OK]( "OK")
Here goes the log, so you can get better picture of whats happening:
Thanks,
marcel
first of all, thanks, its a great tool, been using it since ... ages, now I would like to help to make it a bit better
If you are using compression function and putting your stuff into a ZIP archive, the ZIP is being created in the temporary area (usually in users directory structures) and afterwards the copy process from temp directory to the final destination takes place.
However, if the destination directory doesn't exist, the archive is being created whatsoever in temp, and once compression is done, Reflector tries to move the file - but here it fails, as expected.
The compression is, of course, the longest running part of the whole backup, so I would expect it to not start at all, if the whole backup process has no chance to succeed. Once the ZIP file is successfully built, but the destination doesn't exist, Reflector deletes it from the temp, game over.
I would appreciate if Reflector could check the destination directory before starting the compression, so user doesn't have to wait XY minutes just to find out it was wasted time and he's on the start again.
It happens to me many times, when I make backups on external drive, that the drive sometimes gets assigned different volume letter from OS Windows.
User doesn't have to notice such change, so a quick pre-check would come in handy.
Here goes the log, so you can get better picture of whats happening:
Code:
2023-08-06 19:50:42 A backup has started... 2023-08-06 19:50:42 Backing up the task "BKP-D-na-F-Transcend" 2023-08-06 19:50:42 Applying the parameters to the task "BKP-D-na-F-Transcend" (if any). 2023-08-06 19:50:42 Starting the copy. The user running the task is: marcel 2023-08-06 19:50:42 The directory "C:\D" is being added to the monolithic archive... 2023-08-06 19:59:50 Checking the archive "C:\Users\marcel\AppData\Local\Temp\61605226-8c79-4d62-b749-83ebfd736ff3\D.zip"... 2023-08-06 20:02:32 The monolithic archive "D.zip" has been created. Files in archive: 19714. Folders: 2316. Ignored files: 0 Uncompressed size: 11.37 GB [b]ERR 2023-08-06 20:02:32 The destination directory "F:\bkp-D" couldn't be created: (3) The system cannot find the path specified: [F:\bkp-D][/b] [b]2023-08-06 20:02:33 The temporary directory "C:\Users\marcel\AppData\Local\Temp\61605226-8c79-4d62-b749-83ebfd736ff3" has been successfully deleted.[/b] 2023-08-06 20:02:34 ** Backup for the task "BKP-D-na-F-Transcend" has ended ** 2023-08-06 20:02:34 ** Processed files: 19714. Backed up files: 19714. Created folders: 0. Backup size: 0 bytes. ** 2023-08-06 20:02:34 ** Number of errors: 1. Time elapsed: 0 hours, [b]11 minutes[/b], 51 seconds. **Thanks,
marcel
Statistics: Posted by marcel — 06 Aug 2023, 20:46 — Replies 1 — Views 11