[Samba] DOS dir command on Samba share

[Stan Hoeppner]

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