July 8, 2008 09:03pm pdt

1. sanjooz 2,000
1. omarfarid 2,000
3. cedarghost 1,700
4. owenslef... 1,500
5. MrLonandB 1,250
6. PeturIng... 1,000
7. JustUNIX 900
8. steezy 800
9. sjm_ee 600
10. and235100 500
10. archang3l 500
10. b0lsc0tt 500
10. ubig 500
10. mcse2007 500
15. kiolqc 200

1. mzalfres 2,500
2. sanjooz 2,000
2. omarfarid 2,000
2. TeRReF 2,000
2. Mysidia 2,000
2. Jonvee 2,000
7. cedarghost 1,700
8. owenslef... 1,500
8. m1tk4 1,500
8. patrickab 1,500
8. ygoutham 1,500
12. MrLonandB 1,250
13. PeturIng... 1,000
13. uetian1707 1,000
13. thomaswr... 1,000
13. Liganic 1,000
13. ShineOn 1,000
13. ibu1 1,000
13. BrianGEF... 1,000
13. natoka 1,000

05.21.2007 at 12:05PM PDT, ID: 22585502

	[x] Attachment Details

[x]

The Solution Rating System

With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating.

The Grade of the Solution
The Zone Rank of the Expert Providing the Solution
The Number of Author and Expert Comments
The Number of Experts Contributing
The Feedback of the Community

Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site.

If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support.

Thank you!

7.6

File times on a Win2K3 server from a Linux SMB client are rounded to 2 second intervals - how can we keep original file times?

Zones: Samba File Sharing, Linux Networking, Windows 2003 Server

Tags: samba, file, linux

We are having a problem where the file times on files shared by a Windows Server 2003 server and accessed by a Linux client via an SMB mount are being rounded to the next lower 2 second interval.

This seems to be the same problem that the "dos filetime resolution" setting in smb.conf was designed to handle; however:
a) this setting appears to only affect Samba shares shared by a *nix server (vs our shares being on a Windows server),
b) this is already set to "false" in smb.conf on the Linux machine

I can't find anything comparable on either the smbmount or mount commands, but the Linux client is acting as if this setting is set to "true" at the smbclient level. Any file creation/update commands (touch, cp, vi, etc) run on the Linux client against any file hosted on the Windows server all create a file whose time is rounded to 2 second intervals. (Running equivalent commands from a Windows client attached to the same shared resource generate files with the correct timestamp, so the problem appears to be on the Linux side rather than the Windows side.)

The Linux machine is running SuSE 9.0 (2.4.21-291); the Windows server is running "MS Windows Unified Data Storage Server 2003, Standard Edition x64" (WUDSS 2003). This is for a one-time move of a large set of files from the Linux machine to the Windows SAN server, but we'd like to keep the original file times intact when the files are moved.

Start your free trial to view this solution

Question Stats

Zone: Software

Question Asked By: drnavigator

Solution Provided By: mzalfres

Participating Experts: 3

Solution Grade: A

Translate:

Loading Advertisement...

Microsoft

Internet Protocols
Applications

Development
OS

Hardware
Windows Security

Apple

Operating Systems
Hardware

Programming
Networking

Software

Internet

Search Engines
File Sharing
WebTrends / Stats
Spy / Ad Blockers

Web Browsers
New Net Users
Web Development
Chat / IM

Anti Spam
Web Servers
Anti-Virus
Email Clients

Gamers

Tips
Online / MMORPG
Puzzle
Emulators

Action / Adventure
Role Playing
Consoles
Game Programming

Strategy
Sports
Misc
Computer Games

Digital Living

Hardware
New Net Users
New Users

Software
Digital Music
Gaming World

Home Security
Apple
Networking Hardware

Virus & Spyware

Vulnerabilities
IDS
Encryption
Anti-Virus

Operating Systems Security
Software Firewalls
WebApplications
Cell Phones

Operating Systems
Internet
Hardware Firewalls

Hardware

Handhelds / PDAs
Displays / Monitors
Components
Networking Hardware

Peripherals
Laptops/Notebooks
Storage
Servers

Desktops
New Users
Misc
Apple

Software

System Utilities
Industry Specific
Network Management
Photos / Graphics
Page Layout
VMWare
Misc
Web Development

OS
CYGWIN
Voice Recognition
Message Queue
Quality Assurance
Security
Firewalls
MultiMedia Applications

Development
Database
Office / Productivity
Business Management
OS/2 Apps
Server Software
Internet / Email

ITPro

OS
Storage
Encryption
Operating Systems Security
Apple Hardware
Laptops & Notebooks
Servers
Networking Hardware
Peripherals

Devices
Displays / Monitors
WebTrends / Stats
Search Engines
Firewalls
WebApplications
IDS
Vulnerabilities
Email Clients

File Sharing
Spy / Ad Blockers
Web Browsers
Web Servers
Networking
Anti-Virus
Chat / IM
Anti Spam

Developer

Web Servers
Web Browsers
Game Programming
Dev Tools
Industry Specific
Office / Productivity

Database
CYGWIN
Web Development
Search Engines
File Sharing
WebTrends / Stats

Programming
Content Management
Application Servers
Protocols

Storage

Removable Backup Media
Storage Technology
Servers

Grid
Remote Access
Backup / Restore

Misc
Hard Drives

Miscellaneous
Security
Development
Linux
VMWare

MainFrame OS
Unix
Apple
OS / 2
AS / 400

BeOS
Microsoft
VMS / OpenVMS

Database

Oracle
Miscellaneous
MySQL
Software
Sybase
Contact Management
PostgreSQL
Data Manipulation
Clarion
InterSystems Cache

Siebel
MUMPS
OLAP
SQLBase
SAS
GIS & GPS
4GL
Berkeley DB
DB2
Informix

Interbase / Firebird
FoxPro
Reporting
LDAP
Filemaker Pro
MS SQL Server
dBase
MS Access

Security

Misc
Web Browsers
Software Firewalls
Operating Systems Security
File Sharing

Spy / Ad Blockers
Vulnerabilities
WebApplications
IDS
Anti-Virus

Encryption
Anti Spam
Email Clients
VPN
Chat / IM

Programming

Editors IDEs
Installation
Handhelds / PDAs
Multimedia Programming
System / Kernel

Algorithms
Game
Signal Processing
Project Management
Open Source

Database
Misc
Languages
Processor Platforms
Theory

Web Development

Scripting
Blogs
Web Servers
Software
Search Engines
Web Graphics
Images

Internet Marketing
Images and Photos
Components
Document Imaging
Web Languages/Standards
Illustration
WebApplications

Fonts
WebTrends / Stats
Authoring
Digital Camera Software
Miscellaneous

Networking

Protocols
Apple Networking
Network Management
Message Queue
Application Servers
Content Management
File Servers
Email Servers
Misc
Java Editors & IDEs

Wireless
Networking Hardware
Backup / Restore
System Utilities
ISPs & Hosting
Web Servers
Storage Technology
Removable Backup Media
Servers
Broadband

Grid
OS / 2
Novell Netware
Unix Networking
Windows Networking
Security
Telecommunications
Operating Systems
Linux Networking

Other

Community Advisor
Lounge
Community Support
New Net Users

Philosophy / Religion
Math / Science
Miscellaneous
URLs

Expert Lounge
Politics
Puzzles / Riddles

Community Support

Suggestions
New to EE
New Topics
Community Advisor

CleanUp
Announcements
General

Feedback
Input
EE Bugs

05.21.2007 at 04:18PM PDT, ID: 19130759

mzalfres:

Simplest way, also can make transfer faster - use 'tar' utility to compress your files on linux side, then uncompress them on windows with standard windows tools (no need to install additional software). In case of problems you can use 'zip' on linux instead of tar.
So, the procedure of file transfer will be following:

linux:
cd /some/directory
tar xvfp archive.tar subdir_to_be_archived

then transfer file archive.tar to windows machine and uncompress.
This should also improve speed of transfering large number of small files, but requires some additional space for uncompressed archive.

In case, your space is limited, you can try to compress with zip, as tar is just putting files together into a big one, without compressing, or add option 'z' to tar, to make compressed archive, like in example below. Then you'll need some software like winzip to uncompress it on windows side:

cd /some/directory
tar xvfpz archive.tar.gz subdir_to_be_archived

Accepted Solution

05.22.2007 at 03:57AM PDT, ID: 19132830

drnavigator:

That might be one possible workaround, but unfortunately one that in our situation would take a fairly large effort and a large amount of time to do. In this specific case we have some 30+ million files distributed fairly evenly over 32,000 directories taking 1.3 TB of disk space, growing at the rate of 3-4 GB/day and with less than 40 GB free on the hard drives where they are currently stored. (One of the reasons we ended up using Samba to move the files over rather than SCP was because copying the files over a Samba mount only takes 3-4 days to do vs the 15+ days we had calculated it would take over SCP. [Cygwin SCP and RSYNC under Windows isn't buffered, so it's a BIT slower...]) The bottleneck even with Samba is now the disk access on the old machines, so even if we moved some of the files to free up space for TAR files of 100 GB / 1 million files or so, it would still take a large amount of time to TAR those files. (Might still be a possibility though.)

05.26.2007 at 07:13PM PDT, ID: 19163306

Rank: Master

ShineOn:

How about installing Windows Services for Unix on the W2K3 server, and connect via NSS? I'd think that'd be preferable to using Samba, but that's me...

Or has that been explored and discarded as well?

Assisted Solution

06.11.2007 at 09:55AM PDT, ID: 19259600

Rank: Master

omarfarid:

Hi,

Can you confirm if both servers are using ntp to sync time?

If each server is using its own clock, then you can not get time sync between the two.

You need to use ntp server.

06.11.2007 at 11:40AM PDT, ID: 19260440

Rank: Master

ShineOn:

Is your Samba "share" on a FAT filesystem? FAT timestamps have a 2 second granularity.

If you use CIFSFS, it should have a granularity of 100 nanoseconds, which is the granularity of NTFS timestamps.

Filesystems in Linux can use whatever granularity is specified in the s_time_gran mask used at FS compile time, down to the 1 nanosecond default for JFS.

Your actual timestamp granularity depends on the filesystem you're using, not what Samba is reporting. If you're using a FAT filesystem but Samba's reporting it as NTFS, it will cause filestamp-related issues because of FAT's 2 second granularity vs NTFS' 100 nanoseconds. If you use EXT3 or Rieser, you'll still have timestamp granularity issues because they use 1-second granularity. To match perfectly with Windows NTFS timestamps it seems that you should use the CIFSFS filesystem.

I wonder why I haven't seen anything of that nature in any of the Samba docs I've read so far. You'd think it would have a big "we recommend CIFSFS for Samba shares" somewhere in a readme or something like that... ;)

06.19.2007 at 10:21AM PDT, ID: 19317931

drnavigator:

The Win2K3 server is actually running Windows Unified Data Storage Server 2003 (so supports NFS as well as SMB shares, among other things) so we could copy the files via an NFS mount, but there were issues with what permissions or ownership was applied when copying the files that way so we opted to use SAMBA copying instead. (Don't remember the specifics.)

The Win2K3 side is on an NTFS partition so time resolution isn't a problem. Touching a file on the Win2K3 side shows an accurate time. Also, copying the files via "scp" or "rsync" from the Linux side to the Windows side shows the correct times on the Windows side (vs copying via "cp" over a SAMBA mount from Linux to Windows showing times rounded down to the 2-second intervals). However, scp and rsync from a Linux host to a Cygwin server is an order of magnitude slower than the SAMBA copy (or scp / rsync between Linux hosts). (Something to do with buffering, or lack thereof, in the Cygwin code.)

Ultimately due to time constraints we just copied the files and decided to ignore the time differences, just going with the "new" times instead, so no need to continue further on this.

Will split points between mzalfres and ShineOn since both offered viable alternatives to at least getting the files over in a way that would have worked. (Thanks!)

06.19.2007 at 11:10AM PDT, ID: 19318321

Rank: Master

ShineOn:

It's very likely to be the granularity then. Something in your samba config was doing a time granularity translation more than likely. Maybe it was configured to present itself as FAT and Windows assumed anything from FAT would have a 2-second granularity. I know there's settings in robocopy for copying from FAT so the sync functionality would work...

20080236-EE-VQP-29