Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have several .JPG files and I want them to be .jpg files but every suggested rename script uses "mv" and the manual page (on Mountain Lion) for mv says it does a copy and delete which explains why when I run the script the "created/modified/etc" dates are all changed to the current date. I don't want that to happen. What can I do?

share|improve this question
    
cp -p source.JPG destination.jpg ; rm source.JPG –  Frands Hansen Sep 16 '12 at 22:15
    
@FrandsHansen No. That doesn't work. I get an error saying the two files are identical. –  Sheldon McGee Sep 17 '12 at 23:12
    
make a new dir for them then.. –  Frands Hansen Sep 18 '12 at 11:57
    
@FrandsHansen That changes the date. The point here is that I don't want the dates changed. Been so long I'm starting to think it's impossible. –  Sheldon McGee Sep 19 '12 at 19:28
    
Yes it can :) I have added an answer to explain it. –  Frands Hansen Sep 19 '12 at 20:50

2 Answers 2

So, I want to mess around with these. I even found a good old file, modified in 2006.

$ stat -f "%m%t%Sm %N" *
1347657595  Sep 14 23:19:55 2012 1.JPG
1347715529  Sep 15 15:25:29 2012 2.JPG
1156277764  Aug 22 22:16:04 2006 3.JPG
1347657554  Sep 14 23:19:14 2012 4.JPG
1347657554  Sep 14 23:19:14 2012 5.JPG
1347741772  Sep 15 22:42:52 2012 6.JPG

Make a new dir for them

$ mkdir renamed

Run through them with a loop

$ for i in *.JPG ; do cp -p $i renamed/`echo $i|sed 's/JPG$/jpg/g'` ; rm $i ; done

Now, they're in newdir and removed from current dir. But we want them back - can't use mv though.

$ for i in renamed/* ; do cp -p $i . ; rm $i ; done
$ rm -rf renamed/

Tadaa

$ stat -f "%m%t%Sm %N" *
1347657595  Sep 14 23:19:55 2012 1.jpg
1347715529  Sep 15 15:25:29 2012 2.jpg
1156277764  Aug 22 22:16:04 2006 3.jpg
1347657554  Sep 14 23:19:14 2012 4.jpg
1347657554  Sep 14 23:19:14 2012 5.jpg
1347741772  Sep 15 22:42:52 2012 6.jpg
share|improve this answer
    
Okay, so, to be clear, when you used mv the dates WERE changed, right?? –  Sheldon McGee Sep 20 '12 at 21:15
    
I never used mv, because as you correctly state, mv will change the attribute. When I said "make a new directory" i didn't mean to use mv, just cp, to get past the case sensitivity issue. –  Frands Hansen Sep 21 '12 at 17:09
    
Good it's not just me. I don't get why the dates would change on a move. And I really don't get why they don't change when you rename in the finder but they do when you rename in the Terminal. Thanks though! This will work. –  Sheldon McGee Sep 24 '12 at 17:44

Use touch -r to set the timestamp of one file to another.

cp oldfile newfile
touch -r oldfile newfile

That touch says "Set the timestamp of newfile to the timestamp of oldfile."

Here's a blog post with more about touch and how to use it.

All of that copy + touch should not be necessary, though. You say that the manual says that "mv says it does a copy and delete" but that's not accurate. I'm thinking you may have misread it. You should be able to use mv to rename a file. You may be running into a problem because on HFS+, the Mac filesystem, filenames are case-insensitive, so "foo.jpg" is the same as "FOO.JPG".

share|improve this answer
    
+1 for touch. Just note that the copy in this instance must be to a different folder because the file system is case insensitive. –  John Gardeniers Sep 19 '12 at 23:22
    
cp -p oldfile newfile does the same thing with just 1 command rather than 2. The problem is the whole case insensitivity thing. –  Frands Hansen Sep 20 '12 at 14:25
    
Every time I copy a file the timestamps are changed. Is that a system setting then? I haven't changed many things from the defaults. If I rename from the finder, the timestamps are unchanged. –  Sheldon McGee Sep 20 '12 at 21:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.