[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-tar] Bug? Where? Why? Why so many files changing as we read the
From: |
Linda A. Walsh |
Subject: |
Re: [Bug-tar] Bug? Where? Why? Why so many files changing as we read them? |
Date: |
Mon, 26 Oct 2015 14:30:14 -0700 |
User-agent: |
Thunderbird |
Pavel Raiskup wrote:
Try 'stat' on this file before/after running 'tar -c'. See '10.1.3 Race
conditions' section in documentation [1].
----
Well the 78 messages come out sprinkled throughout a 60-70K file dump.
It doesn't seem a 'stat' would be practical to try to isolate 1 in 1000
files for a change that "might" be occurring...
I'm already familiar with the concepts in section 10.1.3, but as
I mentioned, those files belonged to apps that weren't in use, and
in come cases haven't been used for quite some time. Their
last-mod times indicated that all the files
and the directory hadn't been changed in some time.
FWIW, the volume it was accessing has 'last-accessed' time turned off,
but I think it also has semantics similar to linux kernel's default
last-access time update (i.e. if writing to inode and updating other stuff,
then make sure last-access time is no earlier than other time/date fields
in the inode. The only think accessing them would have been tar, and the
occasional cosmic ray, but tar should handle the 1st case... ;-)
Either make sure tar is the
only process working with those files (globally as that is CIFS mount
point, not only on your machine)
----
That's the thing. It *is* only a CIFS mount point on my machine.
I'm the only user on either of the machines. The link between the machines
is a cross-over wire (no routers or switches) @ 10Gb, so the connection is
the Win7 workstation's is a dedicated link to a linux server, who's only
function is to handle the Win7's internet & disk needs.... so -- single
user.
I.e. "--warning=no-file-changed" would only hide the symptom -- not
explain
or prevent the cause. ;-(