[g.l.d.user] Re: command to mv files & folders to dir

[Ivan Shmakov <ivan@gray.siamics.net>]

>>>>> Mark Panen <mark.panen@gmail.com> writes:
>>>>> On Sat, Sep 24, 2011 at 1:12 PM, Ivan Shmakov wrote:
>>>>> Mark Panen <mark.panen@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