[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 15 Date : 2001-05-12 Author : Kan Yabumoto Subject : Re: XXCOPY in a Netware Mapped drive Size(KB) : 4
The incremental backup (/BI, which is a component in /CLONE) bases its decision whether or not to copy a file upon the file size *AND* file's timestamp. When you mix the type of the file system, the file-time translation which is performed by the respective file system causes subtle problems. I assume that your W2K drive uses an NTFS partition rather than the FAT partition. That causes the following problem: 1. an NTFS volume stores the file date in a 64-bit format which has the precision of 100 nsec. (In my opinion, it's an overkill but better than the 2-second granularity used by the FAT format). 2. I believe the NetWare file system is basically DOS compatible and therefore 2-second granularity (a 16-bit value for the date and another 16-bit value for time). Similarly, if you have a Unix/Linux based file system, again the granularity of the timestamp is different (1 second). So, whenever you copy a file from a volume with a fine-timestamp into a volume with a coarser timestamp, the file time will be converted. Therefore, when you perform an incremental backup using the standard file-time comparison, nearly all files end up being copied again. (When you transfer files between DOS and Unix system, roughly a half of the files will be affected by this). The current release version (v.2.44.4) had the following switch to cope with the 2-second granularity problem. /FT File-time truncation (round down to 2 sec interval) This one works fine between FAT and Unix/Linux systems. However, it turned out to be inadequate in many cases including the case you are dealing with. So, we added the /FR switch that rounds up to the nearest 2-second interval. This treatment is not quite intuitive from programmer's instinct. But, probably, Microsofties chose to adjust the timestamp for "chronologically next valid value. That is how a Win32 program is expected to adjust the file-time granularity. Starting with the current XXCOPY beta test version, you can use /FR File-time round up The XXCOPY beta version which supports this one is available at ftp://ftp.xxcopy.com/download/xcpy2557.zip To make the long story short, you should add the /FR switch along with the /BI (or /CLONE) switch to eliminate the problem you are observing. Admittedly, the question of whether to use /FT or /FR is a little murky. I suppose when you are dealing with the combination of NTFS vs FAT as in your case, the /FR switch is probably the right one. As an implementor of XXCOPY, I would like to make a deterministic (precise) control in its behavior using the explicit /FR or /FT. However, from user's point of view, probably, ignoring the difference in file time within two seconds when file times are compared is simpler (and works in almost all cases) and therefore easier to use, albeit not purists liking. As a matter of fact, Microsoft's ROBOCOPY does exactly that. Therefore I'm contemplating to add yet another switch /FF (stands for fuzzy filetime) which allows you to specify the tolerance in filetime comparison. For now, use /FR (or /FT) to deal with the filetime. Kan Yabumoto ---------------------------------------------------------------------- At 2001-05-12 11:32, you wrote: >Hi, > I must say that xxcopy is really a great tool instead,but I have a >problem here when I tried on several Windows 2000 (w2k) machines with >the same results. > >Probelm >------- > >I have a W2K Advance Server with SP1 and a mapped drive (G:) to a >Netware 4.11 server. > >I did a simple xxcopy or xxcopy with clone switch like below > >xxcopy G:\netware c:\netware or xxcopy G:\netware c:\netware /CLONE > >The end result is that the whole structure under G: goes to c: as >espected. I later did add some files under c:\netware, then ran > >xxcopy G:\netware c:\netware /CLONE > >the additional files get deleted as expected in the c:\netware. Good. > >The problem I have is that all the file date and time being copied >over (sync) to c:\netware don't get preserved. All the copied files >were updated with the latest (local/current) date. Therefore, when I >ran the command with the switch /CLONE, it will just make another >whole copy and updated with the new dates & times. > >I also did the following trial. > >I ran a test run under the local dir, i.e. D:\test to C:\test, with >no problem, it will skip all the same files, everything just work out >perfectly. > >I also ran the noraml xcopy from G:\netware to C:\netware drive, >guess what, the date and time were preserved !!! Similiarly, a simple >XXCOPY from G:\netware to C:\netware without any switch also fail. > >I have read XXCOPY TECHNICAL BULLETIN #21 >(http://www.datman.com/xxcopy/xxcopy21.htm) and tired all the >switches there but ot no avail. > >I just can;t figure out what went wrong. Appreciate if you can >enlight me. Tx. > >Regards, >Max
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.