 |
|
 |
would your program work for non-jpeg (non-exif) files? i have a lot of video and audio media, and simply changing the file properties changes the datestamp... it would be nice to be able to reset folders full of files back to their original creation date without much hassle...
thank you!
00 caren
|
|
|
|
 |
|
 |
Unfortunately video files (to my knowledge) do not have any fields that store original date and time. Although it would be great if they did.
Windows media player has this 'gem' where it can change the modified date of a video file just by playing it! I think I had to turn off default option "Retrieve additional media information from Internet" for it to stop messing with dates on my home videos.
Regards, Damir
|
|
|
|
 |
|
 |
I'm not worried about internal markers, but more along the lines of the operating system's file information... I realize video (and much uncompressed audio) do not have a place for hanging onto that information, so I'd be happy with simply matching the windows datemodified timestamps for the created stamp...
Thanks for the quick response!
|
|
|
|
 |
|
 |
OK, I see what you mean. This functionality is beyond the scope of my tool, but just by quickly modifying the source code it is easy to do what you want. Just skip all the checks for extension and EXIF tag and make modified date = creation date.
Here's the link to modified utility: http://www.filehosting.org/file/details/103104/FileDateChanger.zip[^]
Regards, Damir
|
|
|
|
 |
|
 |
Goodness, I hadn't expected such prompt and wonderful results. Thank you, muchly!
|
|
|
|
 |
|
|
 |
|
 |
I used this code to check over 75000 jpg files on my computer. It is a great utility and thanks for sharing.
I had a couple of snags along the way, so here are a few suggestions if you're still doing any updates to the project.
1) Add the third line below and the corresponding end brace:
if (exifinfo.IsExif) { CString sDatetime = exifinfo.DateTime; if (sDatetime.GetLength()>=19) {
On my computer, I had many JPG files which apparently had exif info (since it made it into the if block), but didn't have the 'date taken' field (when I inspected the string it was ""). Checking the size of sDatetime allowed it to skip files with exif data but an empty 'date taken' field.
2) Move the string to update the dropped/change information into the for loop so it updates after every file processed. It took me a good 20 minutes to process 75000 files, so it helped having some indication of progress.
Also, I have a tip for anyone using this to process a lot of files like I did. Run a copy of FILEMON (sysinternals) and filter on JPGDateChanger.* while this program is running. If anything goes wrong and you get an error, filemon will have a record of the last file JPGDateChanger processed (in my case I had a jpg that came with some software and the field was set to "____:__:__ __:__:__" (the underlines were actually true spaces, but I couldn't get that to show properly in the post). Another time I had a file with a 'read only' flag checked.
Good luck and thanks again.
|
|
|
|
 |
|
 |
Hi,
Thanks for your app, i like it very much. I had the problem that the folder processing didn't work. The reason was the GetFileAttribute function which returns not only FILE_ATTRIBUTE_DIRECTORY but also FILE_ATTRIBUTE_NOT_CONTENT_INDEXED at my Vista PC (i switched off the content indexing service of MS Vista). So i replaced the comparison with a bitweise & expression.
Additionally, i fixed a problem when the app run's the first time (without any registry entries). In this case the combo box has no entry and when you drop a file an assert appears. The combobox entry is only set when the proper registry key exists.
I have some folders where an unexpected error message box appears, I had no time to have a look at that, but I will do.
Maybe this information is useful for you.
best regards, Bernhard
modified on Monday, August 17, 2009 10:36 AM
|
|
|
|
 |
|
 |
Bernhard,
Thanks, for the feedback. If you don't mind, could you send me your fixed version so I could update the article? I checked my code and indeed it was sloppy of me to put == operator instead of checking bit flags for directory attributes.
Regards, Damir
|
|
|
|
 |
|
 |
Damir, you rule! I use a program called "A.F.5 Rename Your Files" to rename all my photos with a custom index -- which starts with the date shot.
When copying files from my Canon pocket camera via USB in Vista, it resets the modified and created dates to the time they're copied over. ARGH!
But your program simply and elegantly fixes it. It would be great to put this on download.com.
THANKS!
|
|
|
|
 |
|
 |
Thanks for the compliment about my program, Eddie! I appreciate it. When I first wrote it, I actually did post it on download.com and some other sites. I just didn't bother to update it there.
Regards, Damir
|
|
|
|
 |
|
 |
It's nice to have this utility to reset the Modify Date, but I much prefer to avoid changing the Modify Date at all. I recommend freeware "JPEG-EXIF autorotate" (http://pilpi.net/software/JPEG-EXIF_autorotate.php) It will rotate a picture, all pictures in a folder, or even all pix in a folder tree, using the orientation flag in the EXIF header (that is, it rotates only pictures that need rotating). It doesn't degrade the picture as Windows Picture Viewer used to; and it resets the orientation flag, so if it's run again nothing happens. Autorotate doesn't tamper with the modify date, either. Everything one could wish -- hundreds of pictures in a minute or two. Works fine with Canon and Panasonic, in my experience.
Also, even if "modify" or "create" date of the picture file is altered (as when copying pictures to a CD-ROM, or e-mailing them) we can still use "Date Picture Taken" stored in the EXIF header -- which gives the date, and the exact hour:minute the photo was taken, assuming the camera has been set to correct time.
|
|
|
|
 |
|
 |
I completely agree with you, Bruce. Windows Picture Viewer is a pretty bad choice for managing your pictures. I was too lazy to look for a decent viewer - root of the problem, and instead concentrated my energy on the effects of the problem.
I have to admit that I barely use this utility myself now because I found very good tool for viewing and managing my pictures: FastStone Image Viewer. It is free! It does everything that commercial program ACDSee used to. Among all other good features, it does "Auto-rotate" on multiple files as well.
Thanks for your comment, Damir Valiulin
|
|
|
|
 |
|
 |
Hi Damir,
Brilliant software, I've been using it for a while but I've just spotted a problem with many of the updates I've done with the software.
On lots of the photo's I've fixed the dates which were all over the place, but now I've noticed that after fixing, the times (dates are OK) shown in the created and modified columns are 1 hour out in relation to the taken time. For example, on particular photo has a time taken of 15:49, but the times created and modified are both 16:49. I've checked this over a couple of hundred different photos from several cameras and the same appears on lots of them. Running the photos through the progam again reports no changes. I'm guessing that the reason is that the photos were taken during summer time (UTC+1 hour) and we're now in winter time (UTC). I don't know if this is a fixable issue, or indeed other people get the same problem?
Thanks, Fliccle.
|
|
|
|
 |
|
 |
Thanks for reporting this Fliccle.
I did some investigating into this and found that this seems to be related with how Windows (perhaps FAT/NTFS file system) handles file times. I noticed that FastStone Image Viewer (program that I know use) reported the same difference for pictures I took in the summer.
So to find which one is the right time, I tried to find some summer pictures in my archive where the was any indication of time right on the picture. I found 2 such pictures, one with a quite clear shot of a wristwatch and one with a clock on a tower. In both cases EXIF tag matched the time displayed on the picture. The file time was 1 hour behind though.
Exactly why this happens is a mystery. I remember seeing similar effect a few times when I tried transferring duplicate pictures from SD card into my repository folder several months after they were shot. Windows asked me if I wanted to overwrite existing file and it showed the time being 1 hour apart.
I wish I could get a better handle on how Windows handles date and time with respect to Daylight Savings, but I can safely conclude that JPGDateChanger is not at fault here.
Thanks again, Damir
|
|
|
|
 |
|
 |
Hi Damir,
The whole area of time stamps is a nightmare. I've seen the same effect in FastStone as well. There's a bit of an artice here explaining why this problem occurs (possibly).
http://support.microsoft.com/kb/158588
Basically it appears that Windows stores the dates as UTC times on the files, then calculates the offsets with when the time zones change (it appears to consider a summer time adjustment as a time zone change). I wonder if my photos will suddenly show the correct timestamps come summertime!
Kind regards, Fliccle
|
|
|
|
 |
|
 |
fliccle wrote: The whole area of time stamps is a nightmare. I've seen the same effect in FastStone as well. There's a bit of an artice here explaining why this problem occurs (possibly).
To be even more blunt: Microsoft's handling of date/time stamps is so severely broken that the file times of existing files will often appear to change by an hour when entering/leaving daylight time; if files are copied from an NTFS partition to a FAT partition during summer/daylight time, and then copied from FAT to NTFS during standard time, the timestamps will be permanently shifted by an hour. Just plain broken.
BTW, what rules does the U.K. use for daylight time? The U.S. used to go from 2:00am the first Sunday in April to 1:59am the last Sunday in October, but we changed the rules recently, so even application which do things the 'right' way will still be hosed when dealing with retrospective data unless they allow it to be processed using different rules for different years.
|
|
|
|
 |
|
 |
I'm not sure about the UK rules exactly, they sound similar to the US ones though. Luckily the UK ones haven't changed. I think Austrailia changed their rules last year because I can remember a Microsoft update being released for it.
|
|
|
|
 |
|
 |
Congratulations on this simple, yet quite effective piece of software! Just what I needed. Works flawlessly and is just one single file. So simple that the manual is just one line!
|
|
|
|
 |
|
 |
I dropped 6.970 files at JPGDateChanger at the same time, but it crashed. How many is it supposed to be able to take in one go?
|
|
|
|
 |
|
 |
Thanks for this big stress test, Curt.
I don't think there is any limit on the amount of files the app can handle. I use DropQueryFile in a loop to get the next dropped file, so unless there's some limit imposed by version of Windows and hardware you are using, you should be OK.
I tried to duplicate your test by gathering together 6956 jpg files (I didn't have so many pics on hand, so I just copied same files multiple times), but after a long delay the app came back with a message that all files were processed. No crash...
It might be a particular JPG file that caused crash? Maybe some malformed EXIF data? Maybe you could run it in the debugger to see what's happening. Unfortunately I can't help you with this problem, since I can't ask you to e-mail me all of those 6,970 pictures 
Regards, Damir
|
|
|
|
 |
|
 |
I haven't tried your app - looks like a good idea. This is something I need from time to time too, but for the date created attribute - when I bring pics from my digital camera to my pc and do a copy (instead of move which retains the attributes since I sort of prefer copy then delete vs move) the date created becomes of course the current date. The date modified is unchanged - the date the pic was taken.
So, if others have this problem (it's not just me) maybe one suggestion would be check boxes on your app to set for whether you want the date created, modified, or both to be updated.
Mostly I have just trained myself (but my forgetfullness prevails sometimes) to do a move instead of copy, but. . . ..would be useful when I forget.
|
|
|
|
 |
|
 |
Kent,
Thanks for the suggestion. This should be very simple to do. I'll probably just add a combo above the "keep window on top" checkbox with 3 choices: "date modified", "date created", "created and modified". Then store the choice in the registry. I'll post reply here when I update the article, so that you'd get notified.
Thanks, Damir
|
|
|
|
 |
|
 |
Thanks, sounds good to me.
|
|
|
|
 |
|
 |
I updated the code and executable. Give it a try.
|
|
|
|
 |