On 10/03/2012 09:23 PM, Ken Moffat wrote: > 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.
The file system is ext3 the same as on each box. Rsync is not an option as only the desktop machine has it at this time. cp -av doesn't work either, the copy never happens but the result in the term shows every thing copied and worked without any error or text saying nothing really happened. BTW I am not concerned with wearing out the sub drive as I have many of the available for use. I don't think that building BLFS will wear one out but if it does I have that covered. >> 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 The perms are for/in my build system to prevent user problems of transfering from one system to another. I use pacman to build the system with and the perms in the final package are correct and not 777. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
