Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
As I recall in the days of DOS and routine use of command.com,
the xcopy command had an option -- I think it was "/a".
When xcopy processed a file, it would alter the state of the archive attribute such that multiple runs of the same command would catch whatever was missed by the previous run. A common use was to fill diskettes and similar small storage media.
xcopy a group of files === rats, media full
xcopy catches more files === repeat ad lib
xcopy eventually catches the last remaining files
The gimmick is that as a file gets processed, it gets marked somehow so that it gets skipped on future runs.
Thanks to all who mentioned rsync and similar. While the copy behavior is valuable and
prompt$ rsync -a ...
is extremely useful, the missing behavior involves the following:
start the file copy
somehow mark the files that get copied
... copy gets interrupted
start the file copy again
marked files get skipped this time
I can see that the timestamp aspects of rsync behavior might satisfy the requirement to copy
those files that were marked and missed. Specifically, if rsync wants to copy this time because
of the timestamp, it ought to want to copy after the interruption. Maybe someone can convince me
that this is as good or better than the xcopy -- unconditional copy if marked.
Well ... the "problem" you're facing is that Linux' filesystems
have no notion of an "archive bit". So time-stamps + size really
are the only thing you can go by, unless you invent/write a
process by which you keep track of which files were successfully
copied by writing them out to a file, and reading that in on the
next run to make it skip automagically. rsync does a fabulous job,
alas it won't work too well if the target is a set of media
rather than one target directory structure.
Thanks to all -- for no other reason than you have helped me clarify the behavior that I seek.
1. Start a copy
2. some files succeed THIS time
3. re-start a copy
4. work on files that were not copied yet
5. some files succeed THIS (2nd) time
9. work on files that were not copied yet
10. all files finally succeed
I'll see what unison and rsync can do. Then, I'll report back.