[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 17 Date : 2001-05-13 Author : max08122000@y... Subject : Re: XXCOPY in a Netware Mapped drive Size(KB) : 5
Hi, I really appreciate the fast respond. What I don't understand is that why the simple NT's xcopy or copy works or preserves the date and time in this case.? I'll get a FAT volume up in the w2k svr (how about FAT32?) to give it another try and also the v2557 version. Cheers. Regards, MAX --- In xxcopy@y..., Kan Yabumoto XXCOPY tech wrote: > > 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.