Bug 41129 - samba 'stat' ctime unstable. manifests as tar 'file changed as we read it' warning
samba 'stat' ctime unstable. manifests as tar 'file changed as we read it' wa...
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: tar (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-17 15:28 EDT by Stephen Samuel
Modified: 2007-04-18 12:33 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 14:21:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen Samuel 2001-05-17 15:28:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.19-6.2.1 i686)

Description of problem:
The samba 'stat' call does not return consistent results. Immediatly after
getting file information from a directory, the first file 'stat'ed gets one
ctime.  If the file is read and then a second 'stat' is done, the ctime
usually differs by about 2 seconds.

This originally manifested as tar printing spurious 'file changed as we
read it' messages.

This error occurs on wolverine (7.0.91) mounting a remote NT filesystem. I
haven't currently found a 7.1 system with access to an NT Samba mount to
test this on.

How reproducible:
Always

Steps to Reproduce:
cd to a samba directory, and run the following script:

filecount=0
find . -type f -print | while read name ; do 
ls -la  "`dirname "$name"`" > /dev/null 
        stat "$name" | grep -v Access > /tmp/f1

filecount=$(( $filecount + 1 ))
echo -n '#'$filecount' '
        for  i in  0  ; do 
           for  j in  0 1 ; do 
                sleep 1
                echo -n $i$j' '
                cp /tmp/f1 /tmp/f2
                wc "$name" > /dev/null
                stat "$name" | grep -v Access > /tmp/f1
                diff /tmp/f1 /tmp/f2 || echo " ::::: ""$name"
           done
        done
if [ $(( $filecount % 10 )) -eq 0 ] ;then echo ; fi
done

Actual Results:  #1 00 5c5
< Change: Thu Mar 15 17:37:40 2001
---
> Change: Thu Mar 15 17:37:39 2001
 ::::: ./ClientArchives/00-1081/a/00-1081a-cor.tif
01 #2 00 5c5
< Change: Thu Mar 15 17:39:48 2001
---
> Change: Thu Mar 15 17:39:47 2001
 ::::: ./ClientArchives/00-1081/a/00-1081a-oth.tif
01 #3 00 5c5
< Change: Thu Mar 15 17:36:36 2001
---
> Change: Thu Mar 15 17:36:35 2001
 ::::: ./ClientArchives/00-1081/a/00-1081a-rep.tif
01 #4 00 5c5
< Change: Sun Jul 16 12:47:52 2000
---
> Change: Sun Jul 16 12:47:50 2000
 ::::: ./ClientArchives/00-1081/admin/00-1081-con.tif
01 



Expected Results:  #1 00 01 #2 00 01 #3 00 01 #4 00 01 #5 00 01 #6 00 01 #7
00 01 #8 00 01 #9 00 01 #10 00 01 
#11 00 01 #12 00 01 #13 00 01 #14 00 01 #15 00 01 #16 00 01 #17 00 01 #18
00 ^C01 #19 00



Additional info:
Comment 1 Stephen Samuel 2001-05-27 11:51:01 EDT
We have loaded the latest redhat release on this system, and it is still
exhibiting the same error.

I have created a modified version of tar which checks mtime/size rather than
ctime (apparently the old tar approach) using the option --check-mtime 
which seems to work around this problem as it affects tar.
Comment 2 Bernhard Rosenkraenzer 2002-01-22 10:52:30 EST
The right thing to do would be fixing up the smb stat call, but unfortunately 
we can't fix NT. 
But I think some other users will run into the problem, so the tar switch may 
come handy. Please attach your patch.
Comment 3 Zach Gorman 2003-04-25 14:25:52 EDT
I'm on RH9, and tar doesn't seem to be patched to include a --check-mtime 
option or equivalent.

This seems like a worthwhile thing to add, as anyone who tries to back up smb 
shares with tar is likely to run in to the smb ctime problem.

Currently, I work around it in my backup script by processing the stderr output 
of tar to see if the errors are innocuous (i.e., they are limited to "file 
changed as we read it" errors for files on smb mounts).
Comment 4 Bill Nottingham 2006-10-18 14:21:31 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
If this issue is still present in a current Fedora Core release, please
open a new bug with the relevant information.

Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.