>>>>> 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
