Problems with backup up network disk



  • I am trying to back up a network disk (Samba) to my XP machine. It is about
    1 Gb, 80,000 files, about 10 directory levels max.

    If I try to schedule a backup job (to zip) using PA, it runs, but only archives about 15% of it all. No error messages. If I try to directly zip from PA, using deflate 64, it does much the same thing. There does not seem to be anything special where it stops.

    If I back up the drive using the pacomp command line utility, I do not get errors, and it seems to put all or almost all files in the archive. paext and info-zip unzip do not seem to see anything wrong with this archive, and the number of files is in the ballpark.

    However, if I open the same archive with PA, it only sees about 15% of the files and storage. No error messages. If I run test from the menu, it finds no errors, though it still only sees about 15%.

    I tried earlier to back this drive up with zipbackup, which seemed to work, but zipbackup could not read the archive it had created, and info-zip said it was bad, though it could read at least some of it. When I opened this same archive in PA, PA did not see anything wrong with it, and apparently saw all 80,000 files.

    What is going on here? It is self-evident from the archive sizes that the backups created within PA are incomplete, but is there any way to check whether the one created by pacomp is? Paexp test sees no
    problems.


  • conexware

    Hi,

    What version of PA are you using? PACL does not support extended zip specs, so it wont be fine for sure.



  • @spwolf:

    Hi,

    What version of PA are you using? PACL does not support extended zip specs, so it wont be fine for sure.

    I use the latest version of PA and PACL, downloaded wednesday. I did some more poking around and think I now have a good idea what is going on.

    The PACL command line utilities seem to handle zipping and unzipping this disk fine, with two minor problems that you may want to look at:

    1. pacomp.exe with the -w switch will
      backup hidden files, but it does not back up hidden folders. I have to explicitly add the hidden directory names to the command line to get them backed up, like

    PACOMP -r -w …. Z:*.* Z:.mutt*.*

    1. paext.exe with the -l switch will also redirect the prompt whether or not to overwrite files to the log file. Of course this prompt must still go to the terminal, the file is not going to answer. Or at least note into manual.txt that an overwrite option should be specified.

    2. The problem with PA seems to have been that I had a subfolder folder “MD”, as well as a subfolder “md” in the same folder. This is perfectly OK under Unix, but not possible under Windows. Unix-aware utilities like info-zip, and also pacomp, have no issue with that, but my guess is that both zipbackup and PA use a Windows Explorer engine to process the files and that the engine crashes on it without returning an error code. In any case, after I renamed one of the two subfolders, I was able to make a correct backup from PA (or rather from the context menu,) using deflate 64.

    My idea is to stick with pacomp, because it is faster than PA, but should I worry that I have more than 65,000 files? I expanded all files with paext and compared them to the orginals (PC Magazine’s Window Match will actually do 80,000 files; I was surprised) and there were no differences. Will there be a warning if a limit is exceeded?

    Leon


  • conexware

    Yeah, I definetly would not do anything out of zip specs with PACL.
    There will be no error since the whole engine does not understand anything out of spec.

    Using PA 2006 will be much safer. I suggest that you disable deflate 64, since it is only extra compression strenght (zip 4.5 compatible “unlimited” archive will be created anyway), and PA 2006 should be quite fast actually, even possibly faster than PACL.



  • @spwolf:

    Yeah, I definetly would not do anything out of zip specs with PACL.
    There will be no error since the whole engine does not understand anything out of spec.

    Using PA 2006 will be much safer. I suggest that you disable deflate 64, since it is only extra compression strenght (zip 4.5 compatible “unlimited” archive will be created anyway), and PA 2006 should be quite fast actually, even possibly faster than PACL.

    Thanks, I was indeed thinking that deflate was needed to get the 4.5. Since the pbs script seems to run fine from a batch file, I will use that then. Also, PA has no problems with the hidden directories.

    Leon

    Leon


 

6
Online

9.8k
Users

6.0k
Topics

36.8k
Posts