On 20120730_122543, Paul E Condon wrote: > 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.
Having posted this, which I thought was reasonable, I went and looked at the archives to see what OP (Mark Fletcher) had written. It turns out that all of his investigation was done using commands typed in as root. For me, this thread is a real puzzle. And very scary. Mark: How old is your NAS? What brand? Is it likely that it uses Linux-based open/free software? What vintage? (best guess). IMHO, something bad is happening as we rush into the future. Layers of software can cover bugs in basic functionality. Complexity beyond human comprehension. -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120730200934.gb22...@big.lan.gnu
