Python
GeoTagging Article |






|
|
||||||||||
| Discussion Thread | forums.macosxhints.com/showthread.php?t=79351 |
| Source (HTML) | myTouch.cpp |
| Build code | myTouch.dmg |
To install | Download myTouch.dmg. |
sudo cp /Volumes/myTouch/myTouch /usr/bin/myTouch password: ..... | |
The code in this project develops a command-line utility called myTouch. This does something similar to the UNIX command 'touch' (usage: touch [-acfm] [-r file] [-t [[CC]YY]MMDDhhmm[.SS]] file ...). myTouch has the following syntax:
usage : myTouch [option[=date]]+ file ... option : -all | -createDate | -contentModDate | -attributeModDate | -accessDate | -backupDate date : [-now | [CC]YYDDMMhh[.ss] ] example: myTouch -all=-now Image.jpg
There are number of things which are quite interesting about this project:
The Mac is UNIX and is required to present the 3 unix timestamps: atime (access), ctime (changed) and mtime (modified). However the HFS+ file system actually manages 5 different timestamps. createDate, contentModDate, attributeModDate, accessDate and backupDate. accessDate implements atime, attributeModDate implements ctime and contentModDate implements mtime. However no command-line support is provided for createDate and backupDate. The UNIX command touch -mt 200102030405 filename may modify createDate and contentModDate, however this appears to a wart of FSSetCatalogInfo which I'll discuss in a moment.
The APIs FSGetCatalogInfo and FSSetCatalogInfo are used to obtain and set this information in the filesystem. However FSSetCatalogInfo seems to have a strong desire to impose some undocumented rules:
I've no doubt that these rules are well intended - however they are suspect. I see no reason why you can't set those dates to be anything you desire. I wouldn't be surprised if a future version of MacOSX changed these rules (I'm very tempted to report a bug on the Apple Radar about this).
MacOSX has a number of elegant functions for encoding and decoding dates. You set up a DateFormatter object and either decode a string to a CFDateRef, or encode a string from a CFDateRef. All handling of the locale and daylight saving rules are hidden inside into these APIs. Of course, it takes a while to find your way around all the documents dealing with all of this - however the result is worth the effort. If I ever get round to writing myTouch for Linux or Windows, I'll replace this part of the code with something portable.
There are a myriad of different times definitions in MacOSX. I suspect that there is a lot is legacy stuff which is still a work in progress. There are many date/string conversion APIs which have been deprecated in 10.4. So I've avoided all of those. I won't list stuff I didn't use, because we want to forget about the very existence of those functions.
MacOSX uses an FSRef to refer to a file. Functions which use FSSpec have been deprecated in 10.4 and so I have avoided using them.
I might port this code to work on Linux and Windows in future (for the moment, it's Mac only). Of course the timestamps in the Linux and Windows file systems are different. I believe the both have 3 which correspond to the UNIX atime, ctime and mtime.
I'll have to do the time parsing for myself - however that's probably some fun and can probably be easily done with Lex. For that matter we could probably define a complete date language in Yacc and that would be lots of fun. I'm suspicious of the DataFormatter decode on the Mac anyway, so I'll replace that code if I ever get round to porting myTouch.
I'm very happy to accept comments, feedback and suggestions for any of my articles. I'm always happy to hear you - especially if you have constructive suggestions. And I'm particularily pleased if you can let me know about corrections.
|
Page design © 1996-2007 Robin Mills / webmaster@clanmills.com Updated Friday October 19, 2007 |
|