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/
--
Stan