Stan Hoeppner put forth on 2/1/2010 10:48 PM: > Braxton Neate put forth on 2/1/2010 9:37 PM: >> Hi, >> >> I was wondering if anyone could shed some light on a problem I am having >> with the DOS DIR command on a SMB share. >> >> I have a batch script that copies files from one mapped network drive to >> another. To check that the copy has been sucsessful it creates two text >> files with the output of the command "dir /s <directory> | find "File"" on >> both directories. >> >> We have recently upgraded one of the servers from Windows to Samba running >> on RHEL 5. For some reason now the output of the dir command comes in a >> different order and the total byte size is different on the samba share than >> the native Windows share thus breaking the check. All the file appear to by >> copied correctly though. >> >> I have attached a sample of what happens. >> Any help is greatly appreciated. > > You should be able to fix the directory order issue by setting the environment > variable > > set dircmd=/ogn > > on the Windows machine running the script. The file size discrepancy probably > has to do with the fact that you changed the underlying filesystem from (I > assume) NTFS to one of EXT2/3/4, ReiserFS, XFS, or JFS. Each filesystem may > report slightly different sizes for files and directories. This problem may > be > more difficult to solve. Are you currently using? > > fstype = NTFS or > fstype = Samba > > You may try swapping those and see if it fixes the file size issue. I have no > idea if this will help, but you might try it. However, keep in mind that any > software that attempts to store information in NTFS alternate data streams > will > be unable to do so. For example, the Windows 2000 file viewer, Windows > Explorer, stores image file thumbnail data in ADS on NTFS filesystems. Thus, > if > you enable fstype = NTFS and the underlying FS is say, ext3 or XFS, thumbnail > data will not be written to the AFS as it doesn't exist, and on top of that, > Explorer will not automatically fall back and create a thumbs.db file, which > is > how thumbnail data is handled on FAT32 and all filesystems *other than* NTFS. > Thus, if one has thumbnail view enabled on a Samba share containing hundreds > or > thousands of photos, the thumbnail data must be regenerated, for every file, > each time the share is viewed, and this is _painfully_ slow. I took me more a > few hours to figure this out. > > So, again, exporting a *nix Samba share as NTFS will cause unforeseen problems > with applications that expect the AFS to exist on the filesystem. > > It seems your current verification method may not work in the future. Have > you > looked into a fully automated, purpose built tool for this task, such as > rsync? > It may give you some more options and flexibility to accomplish your goals. > > http://samba.anu.edu.au/rsync/
Come to think of it, these file size differences being reported may be directly related to existing alternate data streams on your NTFS volume. -- Stan -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
