On Wed, Oct 03, 2012 at 07:52:14PM -0400, Baho Utot wrote:
>
> Actually it goes much farther for me. It isn't just this package or
> that package but a general direction of linux seems to going down hill (
> in my opinion) faster that a snowball headed for hell. Everyone seems to
> want something new just for the sake of something new. Don't care if it
> is needed or works, just give me something new. Suse, Fedora, arch and
> oracle linux, just not able to work for me. Things that where just
> simple are now complex and I can not trust the result. For example take
> my BLFS scripts that I work on on a desktop machine (x86-64), then
> transfer to a usb drive to compile/test on a i686. I copy them using cp
> -vaur BLFS /media/usb. Then I move the usb to the i686 machine and
> nothing was copied/updated.
>
cp -a is equivalent to cp -dR --preserve=all according to the
current info page. Certainly I just use cp -av to copy things (but,
I use rsync for backups - very slow the first time, much quicker on
subsequent updates). I wonder if -u is the problem : (sorry about
the reformatting when I paste it)
`-u'
`--update'
Do not copy a non-directory that has an existing destination
with
the same or newer modification time. If time stamps are being
preserved, the comparison is to the source time stamp truncated
to
the resolutions of the destination file system and of the
system
calls used to update time stamps; this avoids duplicate work if
several `cp -pu' commands are executed with the same source and
destination. If `--preserve=links' is also specified (like
with
`cp -au' for example), that will take precedence.
Consequently,
depending on the order that files are processed from the
source,
newer files in the destination may be replaced, to mirror hard
links in the source.
Alternatively, it might be a filesystem issue. When I'm away from
home, I tend to back things up onto vfat usb sticks - that is a
stupid filesystem, so I put everything in a compressed tarball and
then just copy the tarball, rather than expecting everything in a
copied directory tree to work out fine. Occasionally, I use ext2 on
sticks (and certainly ext2/3/4 on usb drives), but cheap solid-state
storage doesn't like being written to - often the directory area for
vfat is special, other places are more fragile.
> Another example is a file with 777 perms and a cat shows you nothing,
> you know that the file is not empty ( you put things in it) but cat or
> less shows nothing. Everybody has the perms to look at the file but go
> ahead and try to list and it shows you nothing. When you finally get the
> thing working by digging in to it you find that you lose 30 minutes to
> some user name nonsense.
>
Maybe some security option in the kernel - I don't know, I try to
avoid files with 777 perms. Any package-specifics you wish to share
on this issue ?
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
