>>>>> Mark Panen <mark.pa...@gmail.com> writes: >>>>> On Sat, Sep 24, 2011 at 1:12 PM, Ivan Shmakov wrote: >>>>> Mark Panen <mark.pa...@gmail.com> writes: >>>>> On Sat, Sep 24, 2011 at 11:53 AM, Ivan Shmakov wrote:
[Cross-posting to comp.unix.shell for no good reason at all.] […] >>>> $ mkdir -pv -- /mnt/deer/zebra \ >>>> && find /mnt/deer/ -maxdepth 1 -mindepth 1 -not -name zebra \ >>>> -exec mv --target-directory=/mnt/deer/zebra -- {} + >>> will this mv only the file/folders created on the 22/09/2011, i >>> want the older files etc to stay behind. >> Somehow, I didn't understood that as part of the task. >> The -ctime constraint to find(1) may be helpful here, like: >> $ mkdir -pv -- /mnt/deer/zebra \ >> && find /mnt/deer/ \ >> -maxdepth 1 -mindepth 1 -ctime -3 -not -name zebra \ >> -exec mv --target-directory=/mnt/deer/zebra -- {} + >> However, note that the Unix' “change time” is /not/ the file >> creation time (I know of no Unix filesystem to track the latter), >> but they /should/ coincide in this particular case. >> Note also that if the filesystem under /mnt is not a Unix one (such >> as VFAT), it should be checked whether the ctime is actually set as >> desired. Like: >> $ LC_ALL=C stat -- /mnt/deer/foobar >> (Where foobar is one of the files copied 2011-09-22.) Check if the >> Change: field is set to 2011-09-22. > The command made a folder called zebra and put all the contents of > /mnt/deer in /mnt/deer/zebra so did not achieve my plan, the time > stamp is now set at 24th for all, according to $ LC_ALL=C stat -- > /mnt/deer/, Yes, because renaming the file is also counted as a “status change.” > ctime -3 seems to be the problem. I should've cautioned better about the use of change time as a distinguishing property. Namely, the files that have properly resided in /mnt/deer/ had to be checked for whether their timestamps are distinct to those recently copied there. I see two probably causes for the -ctime failure. First of all, if the other files were also “changed” recently (e. g., their content or access mode changed, or they were renamed, or created), -ctime may have been way too rough a constraint. For these cases, -cmin may fit better, but it's typically harder to use. Also, the filesystem of /mnt/deer/ may somehow lacked the support for change timestamps, or had them behaving differently. That being said, there're still ways to recover, though these are even less straightforward than those for the original problem. E. g., a list of all the filenames directly under the original sources for either /mnt/deer/ or /mnt/deer/zebra/ could be composed. Like, e. g.: $ cd /orig/deer/ && find -mindepth 1 -maxdepth 1 -print > /tmp/deer.list $ cd /orig/zebra/ && find -mindepth 1 -maxdepth 1 -print > /tmp/zebra.list $ (I hereafter assume that filenames do not contain any special codes, such as ASCII LF, or Line Feed, or 10.) Now, as everything is now below /mnt/deer/zebra/, let's try to bring those originally in /orig/deer/ back into /mnt/deer/: $ (while read f ; do \ mv -vi -- /mnt/deer/zebra/"$f" /mnt/deer/"$f" ; \ done) < /tmp/deer.list Of course, the above will consider only the filenames. It's impossible to recover if there were two distinct files under /orig/deer/ and /orig/zebra/ sharing a single (relative) filename. (Though that's mainly because one of them was written over the other thanks either to the original cp(1), or to mv(1) in the recovery attempt above.) -- FSF associate member #7257 -- 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/86pqiphvjk....@gray.siamics.net