Re: CIFS and data integrity

[Paul E Condon <pecondon@mesanetworks.net>]

On 20120730_065640, Mark Fletcher wrote:
> Joe <joe <at> jretrading.com> writes:
> 
> > 
> > On Mon, 30 Jul 2012 01:50:14 +0900
> > Mark Fletcher <mark27q1 <at> gmail.com> wrote:
> > 
> > > 
> > > It looks like what got stored on the NAS is not exactly what was
> > > originally on the host. This is a huge problem for me as it means I
> > > can't rely on backups dumped on that device. Is there something wrong
> > > with the way I am mounting the NAS that is leading to this?
> > > 
> > 
> > Probably. I'd guess it is a matter of permissions. If you create the
> > archive elsewhere, copy it to the NAS, copy it back again, presumably
> > there is no difficulty. I also use a Buffalo NAS, but my backups are
> > created on my server, then copied. It is possible that if the
> > compression and expansion is done on the NAS, that a temp file involved
> > may not have the correct permissions to write, or more likely, amend.
> > But is your backup not running under cron as root?
> > 
> 
> I put the exact commands I was executing in my original post. There's no job
> involved, I am typing these commands at the command prompt. I'll bring a job
> into it once it works reliably. If you read my original post, you can see I
> create the archive on the host's local disk, test it to make sure it is good,
> and then copy it to the NAS in a separate operation. I use the cp command to do
> the copy.
> 
> I'm inclined to rule out a bug in the cp command, which leaves something about
> the way the data is being transferred to my NAS. Hence my concern about whether
> my mount command (again, see details in my original post) was correct.
> 
> And yes, to answer someone else's question, this is reproducible, reliably,
> every time. The copy on the NAS is always the same length as the copy on the
> host's local disk, but diff says they are two different binary files and the one
> on the NAS cannot be extracted.
> 

A quick way to by-pass the permissions issue is to log in as super-user root, 
and type your commands and tests as root. As I understand it, root is unstoppable.
That is why it is so dangerous to use it in day-to-day mucking about. A moments 
inattention and real damaged is done. But... as a test, and you are testing,
use root.




-- 
Paul E Condon           
pecondon@mesanetworks.net