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!
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
Code:
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.
~~~ 0;-Dan
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.