From minc-development@bic.mni.mcgill.ca Sat Mar 1 02:01:44 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Sat, 1 Mar 2003 12:01:44 +1000 Subject: [MINC-development] OS X In-Reply-To: <20030228120230.A8379@sickkids.ca> Message-ID: On Fri, 28 Feb 2003, John G. Sled wrote: > Does 'most of minc' include N3? I have received many requests lately > for the N3 code on OSX. Nope. ;( I have however had a hack at it once or twice to no avail. I can't seem to find an elegant solution around the templates problems with AZgenlib. (or whatever it's name was). On this matter how much of AZgen lib is used by nu_correct? I know it uses the histogram entropy type calculations and a few others. If it is only used in a limited fashion, a more general fix might be for "someone" to invest a bit of time in "libraryising" mincstats and use this as opposed to the more problematic c++ version. Of course if a lot more of AZgen lib is used than that, we are back where we started then. :) a From minc-development@bic.mni.mcgill.ca Sat Mar 1 02:03:01 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Sat, 1 Mar 2003 12:03:01 +1000 Subject: [MINC-development] OS X In-Reply-To: Message-ID: On Fri, 28 Feb 2003, Robert VINCENT wrote: > Speaking of N3, I'm actively working on getting it to build with GCC 3.2 > using automake/autoconf. Hopefully this means we will soon have N3 > working on OS X. May the force be with you. I remember spending many (unsuccessful) nights attempting to get it to compile under n32 using cc and gmake. ;) a From minc-development@bic.mni.mcgill.ca Mon Mar 3 22:06:51 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Mon, 3 Mar 2003 17:06:51 -0500 Subject: [MINC-development] patches for tmpnam Message-ID: <20030303170651.A21424@gate.nmr.mgh.harvard.edu> Hi -- here are the changes I've put in to get rid of gcc warnings from calls to tmpnam(). I've commented out the old code and stuck my changes underneath: volume_io/Prog_utils/files.c: line 810: /*char tmp_name[L_tmpnam+1]; */ /*(void) tmpnam( tmp_name );*/ char tmp_name[11]; strcpy (tmp_name, "tempXXXXXX"); mkstemp(tmp_name); line 843: /*char tmp_name[L_tmpnam+1];*/ char tmp_name[11]; line 904: /*(void) tmpnam( tmp_name ); */ strcpy (tmp_name, "tempXXXXXX"); mkstemp(tmp_name); volume_io/Volumes/volume_cache.c: line 863: /*char tmp_name[L_tmpnam+1];*/ char tmp_name[11]; line 875: /*(void) tmpnam( tmp_name );*/ strcpy(tmp_name, "tempXXXXXX"); (void) mkstemp(tmp_name); I suspect I will also want to do something about the call to tempnam in libsrc/netcdf_convenience.c as well, but haven't yet (I think it will be slightly less trivial to do and keep TMPDIR functionality). --vicka From minc-development@bic.mni.mcgill.ca Thu Mar 6 03:07:06 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Wed, 5 Mar 2003 22:07:06 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030303170651.A21424@gate.nmr.mgh.harvard.edu>; from vicka@nmr.mgh.harvard.edu on Mon, Mar 03, 2003 at 05:06:51PM -0500 References: <20030303170651.A21424@gate.nmr.mgh.harvard.edu> Message-ID: <20030305220706.C7450970@shadow.bic.mni.mcgill.ca> On Mon, Mar 03, 2003 at 05:06:51PM -0500, Vicka Corey wrote: > Hi -- here are the changes I've put in to get rid of gcc warnings > from calls to tmpnam(). The changes you propose will cause file descriptor leakage which is not acceptable, especially not in a library. It's true that you can get around that by closing the file descriptor returned by mkstemp(), but that really misses the point of the warnings. The linker is warning you of a race condition. If the tmpnam() calls are going to be replaced, the race ought to be fixed. There's no point in doing it just to get rid of a link warning. -Steve P.S. GCC 3 no longer emits this particular warning, anyway. P.P.S. The man page for mkstemp() on my system says "Don't use this function, use tmpfile(3) instead. It is better defined and more portable." From minc-development@bic.mni.mcgill.ca Thu Mar 6 19:25:28 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Thu, 6 Mar 2003 14:25:28 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030305220706.C7450970@shadow.bic.mni.mcgill.ca>; from stever@bic.mni.mcgill.ca on Wed, Mar 05, 2003 at 10:07:06PM -0500 References: <20030303170651.A21424@gate.nmr.mgh.harvard.edu> <20030305220706.C7450970@shadow.bic.mni.mcgill.ca> Message-ID: <20030306142528.A17525@gate.nmr.mgh.harvard.edu> On Wed, Mar 05, 2003 at 10:07:06PM -0500, Steve ROBBINS wrote: > On Mon, Mar 03, 2003 at 05:06:51PM -0500, Vicka Corey wrote: > > Hi -- here are the changes I've put in to get rid of gcc warnings > > from calls to tmpnam(). > > The changes you propose will cause file descriptor leakage which > is not acceptable, especially not in a library. > > It's true that you can get around that by closing the file > descriptor returned by mkstemp(), but that really misses the > point of the warnings. The linker is warning you of a race > condition. If the tmpnam() calls are going to be replaced, > the race ought to be fixed. There's no point in doing it just > to get rid of a link warning. Since the warnings were causing various of our developers to modify private copies of your code and use different versions of it and of the compilers, actually getting rid of the warnings is *very* important to us. It's hard to debug your code when you have to wade through a lot of irrelevant output, which is why I'm trying to request changes in the MNI code in the first place. Fixing race condition and leaks is worth doing too, of course, but please don't minimize the need for code to compile cleanly. Did the tmpnam() and tempnam() calls in the code clean up after themselves? If so, the same closes should still work; if not it is at least no worse. > P.S. GCC 3 no longer emits this particular warning, anyway. See above about developers using different versions of compilers. > P.P.S. The man page for mkstemp() on my system says "Don't use this function, > use tmpfile(3) instead. It is better defined and more portable." Under gcc 3.1, the tmpfile() man page says, BUGS These interfaces are provided for System V and ANSI compatibility only. The mkstemp(3) interface is strongly preferred. [...] --vicka From minc-development@bic.mni.mcgill.ca Thu Mar 6 20:10:40 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Thu, 6 Mar 2003 15:10:40 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030306142528.A17525@gate.nmr.mgh.harvard.edu> Message-ID: Hi Vicka, I tend to agree that the annoying linker message is worth fixing, even if the result isn't perfect. But I don't want to create a problem with file descriptor leakage, either. What I've done elsewhere is create a private function named something like "miget_temp_filename(char *)" which calls mkstemp() if that function is available, otherwise it calls tempnam(). This partially fixes the race condition, since the central issue with tempnam() is that it doesn't actually create a file, whereas mkstemp() creates a zero-length file with the permissions 600. I think it is therefore much harder for an attacker to exploit mkstemp() than tempnam(). My scheme requires adding a probe for "mkstemp()" in the configure script, so it's a lot of effort to get rid of one warning. But such is life... I'm happy to make these changes if there is general agreement. Are there other suggestions? Thanks, -bert On Thu, 6 Mar 2003, Vicka Corey wrote: > On Wed, Mar 05, 2003 at 10:07:06PM -0500, Steve ROBBINS wrote: > > On Mon, Mar 03, 2003 at 05:06:51PM -0500, Vicka Corey wrote: > > > Hi -- here are the changes I've put in to get rid of gcc warnings > > > from calls to tmpnam(). > > > > The changes you propose will cause file descriptor leakage which > > is not acceptable, especially not in a library. > > > > It's true that you can get around that by closing the file > > descriptor returned by mkstemp(), but that really misses the > > point of the warnings. The linker is warning you of a race > > condition. If the tmpnam() calls are going to be replaced, > > the race ought to be fixed. There's no point in doing it just > > to get rid of a link warning. > > Since the warnings were causing various of our developers to modify > private copies of your code and use different versions of it and of > the compilers, actually getting rid of the warnings is *very* > important to us. It's hard to debug your code when you have to > wade through a lot of irrelevant output, which is why I'm trying > to request changes in the MNI code in the first place. > > Fixing race condition and leaks is worth doing too, of course, but > please don't minimize the need for code to compile cleanly. > > Did the tmpnam() and tempnam() calls in the code clean up after themselves? > If so, the same closes should still work; if not it is at least no worse. > > > P.S. GCC 3 no longer emits this particular warning, anyway. > > See above about developers using different versions of compilers. > > > P.P.S. The man page for mkstemp() on my system says "Don't use this function, > > use tmpfile(3) instead. It is better defined and more portable." > > Under gcc 3.1, the tmpfile() man page says, > BUGS > These interfaces are provided for System V and ANSI compatibility only. > The mkstemp(3) interface is strongly preferred. > [...] > > --vicka > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From minc-development@bic.mni.mcgill.ca Thu Mar 6 20:51:12 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Thu, 6 Mar 2003 15:51:12 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030306142528.A17525@gate.nmr.mgh.harvard.edu>; from vicka@nmr.mgh.harvard.edu on Thu, Mar 06, 2003 at 02:25:28PM -0500 References: <20030306142528.A17525@gate.nmr.mgh.harvard.edu> <20030303170651.A21424@gate.nmr.mgh.harvard.edu> <20030305220706.C7450970@shadow.bic.mni.mcgill.ca> <20030306142528.A17525@gate.nmr.mgh.harvard.edu> Message-ID: <20030306155112.D7450970@shadow.bic.mni.mcgill.ca> On Thu, Mar 06, 2003 at 02:25:28PM -0500, Vicka Corey wrote: > Fixing race condition and leaks is worth doing too, of course, but > please don't minimize the need for code to compile cleanly. Vicka, I apologize for a poor choice of words. I did not mean to minimize the request. > Did the tmpnam() and tempnam() calls in the code clean up after themselves? > If so, the same closes should still work; if not it is at least no worse. The difference is that tmpnam() and tempnam() do not open files. > > P.P.S. The man page for mkstemp() on my system says "Don't use this function, > > use tmpfile(3) instead. It is better defined and more portable." > > Under gcc 3.1, the tmpfile() man page says, > BUGS > These interfaces are provided for System V and ANSI compatibility only. > The mkstemp(3) interface is strongly preferred. Amusing. I think both tmpfile() and mkstemp() are in POSIX now, anyway, so it probably doesn't matter which is used. On Thu, Mar 06, 2003 at 03:10:40PM -0500, Robert VINCENT wrote: > This partially fixes the race condition, since the central issue with > tempnam() is that it doesn't actually create a file, whereas mkstemp() > creates a zero-length file with the permissions 600. I think it is > therefore much harder for an attacker to exploit mkstemp() than tempnam(). Yes, mkstemp() completely fixes the race condition. Not that I'm particularly worried about race conditions in MINC code. -S From minc-development@bic.mni.mcgill.ca Thu Mar 6 21:02:47 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Thu, 6 Mar 2003 16:02:47 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030306155112.D7450970@shadow.bic.mni.mcgill.ca> Message-ID: On Thu, 6 Mar 2003, Steve ROBBINS wrote: > Yes, mkstemp() completely fixes the race condition. Not that I'm particularly > worried about race conditions in MINC code. > > -S You mean you're not afraid that the next big Internet worm will exploit a vulnerability in minctoraw? Well, OK, I'm not losing sleep about that, either. So should I go ahead and make the change I described? -bert From minc-development@bic.mni.mcgill.ca Thu Mar 6 21:47:28 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Thu, 6 Mar 2003 16:47:28 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: ; from bert@bic.mni.mcgill.ca on Thu, Mar 06, 2003 at 03:10:40PM -0500 References: <20030306142528.A17525@gate.nmr.mgh.harvard.edu> Message-ID: <20030306164728.B17525@gate.nmr.mgh.harvard.edu> On Thu, Mar 06, 2003 at 03:10:40PM -0500, Robert VINCENT wrote: > What I've done elsewhere is create a private function named something like > "miget_temp_filename(char *)" which calls mkstemp() if that function is > available, otherwise it calls tempnam(). This seems at least as reasonable a solution as any proposed thus far :) There is one place (in libsrc/netcdf_convenience.c in 1.1) where there is already a call to tempnam(): newfile = tempname(NULL, NULL) ...apparently so that the TMPDIR environment variable will be checked. I don't think there is any similar functionality for checking the environment in mkstemp. The calls to tmpnam() take just the one argument for file, without directory, and seem to interchange more directly with mkstemp() than the two arguments for tempnam(). Did your solution also use NULL for the first argument to tempnam()? > My scheme requires adding a probe for "mkstemp()" in the configure script, > so it's a lot of effort to get rid of one warning. But such is life... ...in a current Freesurfer development build under gcc 2.96, 270 such errors are generated, which accounts for about 1/4 of the entire output of the build. Centralizing the effort to fix it would be very much worth it, at least to us! thanks, --vicka From minc-development@bic.mni.mcgill.ca Fri Mar 7 03:03:58 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Thu, 6 Mar 2003 22:03:58 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030305220706.C7450970@shadow.bic.mni.mcgill.ca> Message-ID: On Wed, 5 Mar 2003, Steve ROBBINS wrote: > On Mon, Mar 03, 2003 at 05:06:51PM -0500, Vicka Corey wrote: > > Hi -- here are the changes I've put in to get rid of gcc warnings > > from calls to tmpnam(). > > The changes you propose will cause file descriptor leakage which > is not acceptable, especially not in a library. > > It's true that you can get around that by closing the file > descriptor returned by mkstemp(), but that really misses the > point of the warnings. The linker is warning you of a race > condition. If the tmpnam() calls are going to be replaced, > the race ought to be fixed. There's no point in doing it just > to get rid of a link warning. The call to mkstemp should fix the race condition, since it has already created the file. One could then close the descriptor and overwrite the file safely (it belongs to the current user now, so it should be safe). The problem with tmpfile is that it does not return the file name, and it unlinks the file after it is opened - it is truly a temporary file! The minc library needs a filename to feed to gzip. The main issue with mkstemp is that it does not refer to TMPDIR. If tempnam is to be replaced, then Bert's function should be adapted to first check for a TMPDIR setting - this can be useful when tmp space is small and one is either uncompressing large files on the fly, or creating temporary cached volumes with volume_io. Bert's fix of creating a "correct" tempname replacement within the minc library (probably in netcdf_convenience.c) is the way to go. All of the calls to tempnam (and friends) can be replaced with calls to this function. It will then be much easier to iterate over attempts to get it right (right being defined as not leaking descriptors, error messages or features) until everyone is happy. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Fri Mar 7 03:08:49 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Thu, 6 Mar 2003 22:08:49 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030306142528.A17525@gate.nmr.mgh.harvard.edu> Message-ID: On Thu, 6 Mar 2003, Vicka Corey wrote: > Did the tmpnam() and tempnam() calls in the code clean up after themselves? > If so, the same closes should still work; if not it is at least no worse. Those functions do not open descriptors, which is the cause of the race condition in the first place. BTW, does anyone know to what extent this is a security risk? My guess would be that this is only a risk for either root (or setuid root) applications. Have I missed something? [Comments about over-zealous gcc/glibc developers suppressed...] Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Fri Mar 7 18:10:38 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri, 7 Mar 2003 13:10:38 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: Message-ID: On Thu, 6 Mar 2003, Peter NEELIN wrote: > BTW, does anyone know to what extent this is a security risk? My guess > would be that this is only a risk for either root (or setuid > root) applications. Have I missed something? > > [Comments about over-zealous gcc/glibc developers suppressed...] > I think the risk is minor; this isn't like calling gets() on a network socket. So, with thanks to Vicka for pushing the issue, I've made and tested some changes I'd like to propose. In a nutshell, I created a new global minc function named "micreate_tempfile()". I chose this name because I wanted it to reflect the fact that the function actually creates the file, but closes it before returning. The function is obsessively #ifdef'd to deal with systems that define neither mkstemp() nor tempnam(), but hopefully this is just overkill. If I did things right, the function should leak neither memory nor file descriptors. Here's a summary of the files that changed: In configure.in - Added AC_CHECK_FUNCS(mkstemp tempnam tmpnam) In libsrc/netcdf_convenience.c - Added definition of "int micreate_tempfile(char *name_ptr, int name_len)" - Replaced call to tempnam() with call to micreate_tempfile() - Added #include "config.h" - Added #include In libsrc/minc.h - Added declaration of micreate_tempfile(), and MI_MAX_PATH In volume_io/Prog_utils/files.c - Replaced 2 calls to tmpnam() with calls to micreate_tempfile() In volume_io/Volumes/volume_cache.c - Replaced 1 call to tmpnam() with micreate_tempfile() The entire MINC 1.1 source now builds on Linux 7.3 and GCC 2.96 with nary a peep from the linker. Does anyone want to review these changes in detail before I commit them? Is there a preferred way to distribute the changes for review, or do folks just want to examine them in ~bert/projects/minc/cvsroot/minc (which should be world-readable). -bert From minc-development@bic.mni.mcgill.ca Fri Mar 7 18:19:28 2003 From: minc-development@bic.mni.mcgill.ca (Vicka Corey) Date: Fri, 7 Mar 2003 13:19:28 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: ; from bert@bic.mni.mcgill.ca on Fri, Mar 07, 2003 at 01:10:38PM -0500 References: Message-ID: <20030307131928.L17525@gate.nmr.mgh.harvard.edu> On Fri, Mar 07, 2003 at 01:10:38PM -0500, Robert VINCENT wrote: > The entire MINC 1.1 source now builds on Linux 7.3 and GCC 2.96 with nary > a peep from the linker. Does anyone want to review these changes in > detail before I commit them? Is there a preferred way to distribute the > changes for review, or do folks just want to examine them in > ~bert/projects/minc/cvsroot/minc (which should be world-readable). I don't have access to your filesystem, but if you will mail me a tarball, I'd be delighted to try building it under OS X. thanks, --vicka From minc-development@bic.mni.mcgill.ca Sun Mar 9 21:58:27 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Sun, 9 Mar 2003 16:58:27 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: Message-ID: On Fri, 7 Mar 2003, Robert VINCENT wrote: > a peep from the linker. Does anyone want to review these changes in > detail before I commit them? Is there a preferred way to distribute the > changes for review, or do folks just want to examine them in > ~bert/projects/minc/cvsroot/minc (which should be world-readable). If you attach a patch, all readers of the list should be able to see the changes fairly easily. Providing a BIC-specific location as well may be helpful for those who like to see the whole source. Note that you should use diff -u format for the patches. The patches look good, except for a few minor things: - The default values of P_tmpdir should be "/var/tmp". - Watch those strn* functions - they do not append '\0' if they truncate, so you have to do it yourself after every call (or before, and remember to decrement n by 1 first). - Watch strncat - according to the irix man page it limits the number of characters appended to n, so you need to decrement your limit by the number of characters already in the string. - When you call tmpnam, you don't check that tmpfile_len is at least L_tmpnam, so it could overrun. You could pass NULL and then strncpy the result. However, - If the user buffer is too short, would it not make sense to return an error rather than a truncated file name? I don't know what mkstemp does with fewer than six X's. Your comments should probably suggest that the caller allocate a buffer of PATH_MAX+1 characters to be certain that failure does not occur (since TMPDIR can change the length at run time). You seem to have covered all of our previously expressed concerns however (compiler warnings, leaking file descriptors, using TMPDIR) as well as dealing with systems that are missing mkstemp (do we know of any?). Thanks. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Mon Mar 10 14:08:55 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Mon, 10 Mar 2003 09:08:55 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: ; from bert@bic.mni.mcgill.ca on Fri, Mar 07, 2003 at 01:10:38PM -0500 References: Message-ID: <20030310090855.A7878686@shadow.bic.mni.mcgill.ca> On Fri, Mar 07, 2003 at 01:10:38PM -0500, Robert VINCENT wrote: > On Thu, 6 Mar 2003, Peter NEELIN wrote: > > > BTW, does anyone know to what extent this is a security risk? My guess > > would be that this is only a risk for either root (or setuid > > root) applications. Have I missed something? You're correct that it is a *security* risk only when run by root. In other instances, the race is a mere inconvenience: the attacker could make you overwrite any of your files with MINC output. Here's a lucid discussion on the race and problems with tmpnam http://www.linuxselfhelp.com/HOWTO/Secure-Programs-HOWTO/avoid-race.html > So, with thanks to Vicka for pushing the issue, I've made and tested some > changes I'd like to propose. In a nutshell, I created a new global minc > function named "micreate_tempfile()". I chose this name because I wanted > it to reflect the fact that the function actually creates the file, but > closes it before returning. I'm not clear why it is important to reflect that fact. Once the file is closed, the race is on again. > The function is obsessively #ifdef'd to deal > with systems that define neither mkstemp() nor tempnam(), but hopefully > this is just overkill. Surely checking for tempnam() and tmpnam() is overkill -- MINC has been used for years without such checking ;-) It seems to me that you could simplify the logic of the function by closing the file in the HAVE_MKSTEMP block, and refraining from creating & closing the file in other cases (since it buys you nothing). In addition, you could probably simplify your life if the function took no arguments and simply returned a pointer to some malloc()'d memory as the current get_temporary_filename() function does. This has two benefits: (a) you wouldn't have to guess at MI_MAX_PATH, and (b) you can use strlen() before allocating the memory so you don't have to worry about some fool defining TMPDIR to a really long string (longer, say, than MI_MAX_PATH). -S From minc-development@bic.mni.mcgill.ca Mon Mar 10 15:34:19 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Mon, 10 Mar 2003 10:34:19 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030310090855.A7878686@shadow.bic.mni.mcgill.ca> Message-ID: Steve, I thought that having the function create the file avoids the worst aspects of the race condition, since the file is known to have been created successfully with relatively secure permissions and ownership. Closing the file should be immaterial, since the file is known to exist with owner read/write permissions only. However, I realize now that it would be more correct if I used open() with O_EXCL than by using creat(), since some implementations of creat() will not fail if the file already exists. If you prefer that I allocate memory in the function, I'm OK with that, I just have a preference for functions that force the caller to allocate the memory (I get fewer memory leaks that way). -bert > It seems to me that you could simplify the logic of the function > by closing the file in the HAVE_MKSTEMP block, and refraining > from creating & closing the file in other cases (since it buys you > nothing). > > In addition, you could probably simplify your life if the function > took no arguments and simply returned a pointer to some malloc()'d > memory as the current get_temporary_filename() function does. This > has two benefits: (a) you wouldn't have to guess at MI_MAX_PATH, and > (b) you can use strlen() before allocating the memory so you don't > have to worry about some fool defining TMPDIR to a really long string > (longer, say, than MI_MAX_PATH). > > -S > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From minc-development@bic.mni.mcgill.ca Mon Mar 10 16:29:42 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Mon, 10 Mar 2003 11:29:42 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: ; from bert@bic.mni.mcgill.ca on Mon, Mar 10, 2003 at 10:34:19AM -0500 References: <20030310090855.A7878686@shadow.bic.mni.mcgill.ca> Message-ID: <20030310112942.B7878686@shadow.bic.mni.mcgill.ca> On Mon, Mar 10, 2003 at 10:34:19AM -0500, Robert VINCENT wrote: > Steve, > > I thought that having the function create the file avoids the worst > aspects of the race condition, since the file is known to have been > created successfully with relatively secure permissions and ownership. No, that buys you nothing. Once you close the file, all bets are off. > Closing the file should be immaterial, since the file is known to exist > with owner read/write permissions only. More precisely, the file did exist at one time with owner read/write permissions. Once you close it, the file is gone. Anything can happen during the interval that you close and re-open the file. > If you prefer that I allocate memory in the function, I'm OK with that, I > just have a preference for functions that force the caller to allocate > the memory (I get fewer memory leaks that way). I understand your point and favour it when applicable. The trouble in this case is that you also force the caller to guess how much memory to allocate. In addition, it's nicer on client programmers when a library uses a consistent policy with regards to this issue. Volume_io already has get_temporary_filename() which returns allocated memory so why not just promote this function's semantics into MINC proper? -S From minc-development@bic.mni.mcgill.ca Mon Mar 10 23:46:01 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 11 Mar 2003 09:46:01 +1000 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030310112942.B7878686@shadow.bic.mni.mcgill.ca> Message-ID: On Mon, 10 Mar 2003, Steve ROBBINS wrote: > In addition, it's nicer on client programmers when a library uses > a consistent policy with regards to this issue. Volume_io already > has get_temporary_filename() which returns allocated memory so why > not just promote this function's semantics into MINC proper? I have stayed out of this little battle so far but couldn't resist adding my 2c here. a From minc-development@bic.mni.mcgill.ca Wed Mar 12 02:03:55 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Tue, 11 Mar 2003 21:03:55 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: <20030310112942.B7878686@shadow.bic.mni.mcgill.ca> Message-ID: On Mon, 10 Mar 2003, Steve ROBBINS wrote: > On Mon, Mar 10, 2003 at 10:34:19AM -0500, Robert VINCENT wrote: > > > > I thought that having the function create the file avoids the worst > > aspects of the race condition, since the file is known to have been > > created successfully with relatively secure permissions and ownership. > > No, that buys you nothing. Once you close the file, all bets are > off. I'm not sure that this is correct. mkstemp creates the file and returns a file descriptor. The file is NOT unlinked, so closing it leaves it in place with the correct ownership and permissions. Under irix, with the sticky bit set on the /var/tmp directory (as is done at the BIC), other users cannot do malicious things to the file. A subsequent open (from gzip, for example) will truncate the file (if the correct open flags are used) without leaving the race condition open. "man 2 stat" suggests that the same is true under linux. Of course, it is up to the sysadmin to ensure that the permissions are correctly set on the tmp directories, but my Mandrake system does have the sticky bit set on /tmp and /var/tmp, so I'm guessing that most linux distros do it correctly. (I know, that is a bit of an extrapolation!) Please correct me if I am wrong, Steve - I just don't see the hole. > More precisely, the file did exist at one time with owner read/write > permissions. Once you close it, the file is gone. Anything can happen > during the interval that you close and re-open the file. Nope. You're thinking of tmpfile. It unlinks after opening the file. It does not return a file name because using the file name would still suffer from the face condition (the file that once existed with the name still exists, but no longer has a name). > In addition, it's nicer on client programmers when a library uses > a consistent policy with regards to this issue. Volume_io already > has get_temporary_filename() which returns allocated memory so why > not just promote this function's semantics into MINC proper? 'Sounds like a good plan. Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Thu Mar 13 15:35:56 2003 From: minc-development@bic.mni.mcgill.ca (Steve ROBBINS) Date: Thu, 13 Mar 2003 10:35:56 -0500 Subject: [MINC-development] patches for tmpnam In-Reply-To: ; from neelin@bic.mni.mcgill.ca on Tue, Mar 11, 2003 at 09:03:55PM -0500 References: <20030310112942.B7878686@shadow.bic.mni.mcgill.ca> Message-ID: <20030313103556.A8303736@shadow.bic.mni.mcgill.ca> On Tue, Mar 11, 2003 at 09:03:55PM -0500, Peter NEELIN wrote: > On Mon, 10 Mar 2003, Steve ROBBINS wrote: > > > On Mon, Mar 10, 2003 at 10:34:19AM -0500, Robert VINCENT wrote: > > > > > > I thought that having the function create the file avoids the worst > > > aspects of the race condition, since the file is known to have been > > > created successfully with relatively secure permissions and ownership. > > > > No, that buys you nothing. Once you close the file, all bets are > > off. > > I'm not sure that this is correct. mkstemp creates the file and returns a > file descriptor. The file is NOT unlinked, so closing it leaves it in > place with the correct ownership and permissions. You're right. I was somehow thinking that the file got unlinked after opening, but as you say, that is only true of tmpfile(). So for systems that have mkstemp(), there is no race. Excellent! [If mkstemp() is not available, the race remains, but this is no worse than it was previously.] -S From minc-development@bic.mni.mcgill.ca Thu Mar 13 18:54:20 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Thu, 13 Mar 2003 13:54:20 -0500 Subject: [MINC-development] Another pass at micreate_tempfile() Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2066828793-2035456016-1047581660=:8287168 Content-Type: TEXT/PLAIN; charset=US-ASCII After a brief hiatus, here is a revised take on the micreate_tempfile() function for your comments... The new version of the function returns a malloc'd string, or NULL on error. It takes no arguments. The relevant diffs are enclosed. -bert ---2066828793-2035456016-1047581660=:8287168 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="diffs.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="diffs.txt" SW5kZXg6IGNvbmZpZ3VyZS5pbg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K UkNTIGZpbGU6IC9zb2Z0d2FyZS9zb3VyY2UvbWluYy9jdnNyb290L21pbmMv Y29uZmlndXJlLmluLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gNi44DQpkaWZm IC11IC1yNi44IGNvbmZpZ3VyZS5pbg0KLS0tIGNvbmZpZ3VyZS5pbgkxNyBG ZWIgMjAwMyAyMTowMTo1NyAtMDAwMAk2LjgNCisrKyBjb25maWd1cmUuaW4J NyBNYXIgMjAwMyAxNzoxNDoyNiAtMDAwMA0KQEAgLTMzLDYgKzMzLDkgQEAN CiBkbmwgbmVlZCBhYyAyLjU3IGZvciB0aGlzPyBBQ19DT05GSUdfTElCT0JK X0RJUihsaWJzcmMpDQogQUNfUkVQTEFDRV9GVU5DUyhzdHJkdXApDQogDQor ZG5sIFZlcmlmeSBleGlzdGVuY2Ugb2YgbWtzdGVtcCwgdGVtcG5hbSwgYW5k IHRtcG5hbQ0KK0FDX0NIRUNLX0ZVTkNTKG1rc3RlbXAgdGVtcG5hbSB0bXBu YW0pDQorDQogZG5sIFRoaXMgbGluayBpcyBuZWVkZWQgdG8gYWxsb3cgPHZv bHVtZV9pby9mb28uaD4gc3R5bGUgaW5jbHVkZXMuDQogQUNfQ09ORklHX0xJ TktTKHZvbHVtZV9pby9JbmNsdWRlL3ZvbHVtZV9pbzp2b2x1bWVfaW8vSW5j bHVkZSkNCiANCkluZGV4OiBsaWJzcmMvbWluYy5oDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpSQ1MgZmlsZTogL3NvZnR3YXJlL3NvdXJjZS9taW5jL2N2 c3Jvb3QvbWluYy9saWJzcmMvbWluYy5oLHYNCnJldHJpZXZpbmcgcmV2aXNp b24gNi44DQpkaWZmIC11IC1yNi44IG1pbmMuaA0KLS0tIGxpYnNyYy9taW5j LmgJMTMgTm92IDIwMDEgMTQ6MTU6MTcgLTAwMDAJNi44DQorKysgbGlic3Jj L21pbmMuaAkxMCBNYXIgMjAwMyAxODo1NjowNyAtMDAwMA0KQEAgLTQ2Miw2 ICs0NjIsNyBAQA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp bnQgZXhjbHVkZWRfdmFyc1tdKTsNCiBwdWJsaWMgaW50IG1pY29weV9hbGxf dmFyX3ZhbHVlcyhpbnQgaW5jZGZpZCwgaW50IG91dGNkZmlkLCBpbnQgbmV4 Y2x1ZGUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50 IGV4Y2x1ZGVkX3ZhcnNbXSk7DQorcHVibGljIGNoYXIgKm1pY3JlYXRlX3Rl bXBmaWxlKHZvaWQpOw0KIA0KIC8qIEZyb20gbWluY19jb252ZW5pZW5jZS5j ICovDQogcHVibGljIGludCBtaWdldF9kYXRhdHlwZShpbnQgY2RmaWQsIGlu dCBpbWdpZCwgDQoNCkluZGV4OiBsaWJzcmMvbmV0Y2RmX2NvbnZlbmllbmNl LmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvc29mdHdh cmUvc291cmNlL21pbmMvY3Zzcm9vdC9taW5jL2xpYnNyYy9uZXRjZGZfY29u dmVuaWVuY2UuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDYuNw0KZGlmZiAt dSAtcjYuNyBuZXRjZGZfY29udmVuaWVuY2UuYw0KLS0tIGxpYnNyYy9uZXRj ZGZfY29udmVuaWVuY2UuYwkyMCBBdWcgMjAwMSAxMzoxOToxNSAtMDAwMAk2 LjcNCisrKyBsaWJzcmMvbmV0Y2RmX2NvbnZlbmllbmNlLmMJMTMgTWFyIDIw MDMgMTY6MzE6MjQgLTAwMDANCkBAIC0xMzUsMTAgKzEzNSwxMiBAQA0KIHN0 YXRpYyBjaGFyIHJjc2lkW10gPSAiJEhlYWRlcjogL3NvZnR3YXJlL3NvdXJj ZS9taW5jL2N2c3Jvb3QvbWluYy9saWJzcmMvbmV0Y2RmX2NvbnZlbmllbmNl LmMsdiA2LjcgMjAwMS8wOC8yMCAxMzoxOToxNSBuZWVsaW4gRXhwICQgTUlO QyAoTU5JKSI7DQogI2VuZGlmDQogDQorI2luY2x1ZGUgImNvbmZpZy5oIgkJ LyogRnJvbSBjb25maWd1cmUgKi8NCiAjaW5jbHVkZSA8bWluY19wcml2YXRl Lmg+DQogI2lmZGVmIHVuaXgNCiAjaW5jbHVkZSA8dW5pc3RkLmg+DQogI2lu Y2x1ZGUgPHN5cy93YWl0Lmg+DQorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CQkv KiBGb3IgU19JUkVBRCwgU19JV1JJVEUgKi8NCiAjZW5kaWYNCiANCiAvKiBQ cml2YXRlIGZ1bmN0aW9ucyAqLw0KQEAgLTQxOSw3ICs0MjEsNyBAQA0KIA0K ICAgIC8qIENyZWF0ZSBhIHRlbXBvcmFyeSBmaWxlIG5hbWUgKi8NCiAgICBp ZiAodGVtcGZpbGUgPT0gTlVMTCkgew0KLSAgICAgIG5ld2ZpbGUgPSB0ZW1w bmFtKE5VTEwsIE5VTEwpOw0KKyAgICAgbmV3ZmlsZSA9IG1pY3JlYXRlX3Rl bXBmaWxlKCk7DQogICAgfQ0KICAgIGVsc2Ugew0KICAgICAgIG5ld2ZpbGUg PSBzdHJkdXAodGVtcGZpbGUpOw0KQEAgLTE1MjIsNCArMTUyNCwxMDYgQEAN CiANCiAgICBNSV9SRVRVUk4oTUlfTk9FUlJPUik7DQogICAgICAgIA0KK30N CisNCisMDQorLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gTU5J IEhlYWRlciAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K K0BOQU1FICAgICAgIDogbWljcmVhdGVfdGVtcGZpbGUNCitASU5QVVQgICAg ICA6IHZvaWQNCitAT1VUUFVUICAgICA6IChub25lKQ0KK0BSRVRVUk5TICAg IDogUG9pbnRlciB0byBmaWxlbmFtZSAod2hpY2ggbXVzdCBiZSBmcmVlZCks IG9yIE5VTEwgaWYgYW4gZXJyb3INCisgICAgICAgICAgICAgIG9jY3Vycy4N CitAREVTQ1JJUFRJT046IENyZWF0ZXMgYSB0ZW1wb3JhcnkgZmlsZSAod2hp Y2ggaXMgaW5pdGlhbGx5IENMT1NFRCkuDQorQE1FVEhPRCAgICAgOiBVbm5l Y2Vzc2FyaWx5IGNvbnZvbHV0ZWQsIEkgc3VwcG9zZS4uLiBTZWUgY29tbWVu dHMuDQorQEdMT0JBTFMgICAgOiANCitAQ0FMTFMgICAgICA6IFN0YW5kYXJk IFBPU0lYL1VOSVggcm91dGluZXMNCitAQ1JFQVRFRCAgICA6IDA3LU1hcmNo LTIwMDMgYnkgYmVydEBiaWMubW5pLm1jZ2lsbC5jYQ0KK0BNT0RJRklFRCAg IDogDQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLw0KKw0K Ky8qIEZvcmNlIFBfdG1wZGlyIHRvIGJlIHNvbWV0aGluZyByZWFzb25hYmxl LiAqLw0KKyNpZiAhZGVmaW5lZChQX3RtcGRpcikNCisjZGVmaW5lIFBfdG1w ZGlyICIvdmFyL3RtcCINCisjZW5kaWYgLyogUF90bXBkaXIgbm90IGRlZmlu ZWQgKi8NCisNCitwdWJsaWMgY2hhciAqDQorbWljcmVhdGVfdGVtcGZpbGUo dm9pZCkNCit7DQorICBpbnQgdG1wX2ZkOw0KKyAgY2hhciAqdG1wZmlsZV9w dHI7DQorDQorI2lmIGRlZmluZWQgKEhBVkVfTUtTVEVNUCkNCisNCisgIC8q IEJlc3QtY2FzZSBzY2VuYXJpbyAoc28gZmFyLi4uKQ0KKyAgICogbWtzdGVt cCgpIGNyZWF0ZXMgYSBmaWxlIGltbWVkaWF0ZWx5LCBtaW5pbWl6aW5nIHRo ZSByYWNlDQorICAgKiBjb25kaXRpb25zIHRoYXQgZXhpc3Qgd2hlbiB1c2lu ZyB0aGUgb3RoZXIgZnVuY3Rpb25zLiAgVGhlc2UgcmFjZQ0KKyAgICogY29u ZGl0aW9ucyBjYW4gbGVhZCB0byBzbWFsbCBzZWN1cml0eSBob2xlcyAoYW5k IGxhcmdlLCBhbm5veWluZw0KKyAgICogR05VIGxpbmtlciBtZXNzYWdlcyku DQorICAgKg0KKyAgICogVGhlIG9ubHkgY2F0Y2ggaXMgdGhhdCBta3N0ZW1w KCkgZG9lcyBub3QgYXV0b21hdGljYWxseSBwdXQgdGhlIA0KKyAgICogZmls ZSBpbiB0aGUgVE1QRElSIGRpcmVjdG9yeSAob3Igc29tZSBvdGhlciBhcHBy b3ByaWF0ZSBwbGFjZSkuDQorICAgKiBTbyBJIG1vcmUtb3ItbGVzcyBlbXVs YXRlIHRoYXQgYmVoYXZpb3IgaGVyZS4NCisgICAqLw0KKyAgY29uc3QgY2hh ciBwYXRfc3RyW10gPSAiL21pbmMtWFhYWFhYIjsNCisgIGNoYXIgKnRtcGRp cl9wdHI7DQorDQorICBpZiAoKHRtcGRpcl9wdHIgPSBnZXRlbnYoIlRNUERJ UiIpKSA9PSBOVUxMKSB7DQorICAgIHRtcGRpcl9wdHIgPSBQX3RtcGRpcjsN CisgIH0NCisgIHRtcGZpbGVfcHRyID0gbWFsbG9jKHN0cmxlbih0bXBkaXJf cHRyKSArIHNpemVvZiAocGF0X3N0cikpOw0KKyAgaWYgKHRtcGZpbGVfcHRy ICE9IE5VTEwpIHsNCisgICAgc3RyY3B5KHRtcGZpbGVfcHRyLCB0bXBkaXJf cHRyKTsNCisgICAgc3RyY2F0KHRtcGZpbGVfcHRyLCBwYXRfc3RyKTsNCisg ICAgdG1wX2ZkID0gbWtzdGVtcCh0bXBmaWxlX3B0cik7IC8qIENyZWF0ZXMg dGhlIGZpbGUgaWYgcG9zc2libGUuICovDQorICB9DQorICBlbHNlIHsNCisg ICAgdG1wX2ZkID0gLTE7CQkvKiBFcnJvciwgb3V0IG9mIG1lbW9yeSAqLw0K KyAgfQ0KKw0KKyNlbGlmIGRlZmluZWQgKEhBVkVfVEVNUE5BTSkNCisNCisg IC8qIFNlY29uZC1iZXN0IGNhc2UuICBXaGlsZSBub3QgY29tcGxldGVseSBh dm9pZGluZyB0aGUgcmFjZSBjb25kaXRpb24sDQorICAgKiB0aGlzIGFwcHJv YWNoIHNob3VsZCBhdCBsZWFzdCBoYXZlIHRoZSBuaWNlIHByb3BlcnR5IG9m IHB1dHRpbmcgdGhlDQorICAgKiB0ZW1wZmlsZSBpbiB0aGUgcmlnaHQgZGly ZWN0b3J5Lg0KKyAgICovDQorICBpZiAoKHRtcGZpbGVfcHRyID0gdGVtcG5h bShOVUxMLCAibWluYy0iKSkgIT0gTlVMTCkgew0KKyAgICB0bXBfZmQgPSBv cGVuKHRtcGZpbGVfcHRyLCBPX0NSRUFUIHwgT19FWENMIHwgT19SRFdSLA0K KwkJICBTX0lXUklURSB8IFNfSVJFQUQpOyAvKiBDcmVhdGUgdGhlIGZpbGUu ICovDQorICB9DQorDQorI2VsaWYgZGVmaW5lZCAoSEFWRV9UTVBOQU0pDQor ICAvKiBXb3JzdCBjYXNlLiAgdG1wbmFtKCkgaXMgYXBwYXJlbnRseSB0aGUg d29yc3Qgb2YgYWxsIHBvc3NpYmxlIHdvcmxkcw0KKyAgICogaGVyZS4gIEl0 IGRvZXNuJ3QgYWxsb3cgYW55IHdheSB0byBmb3JjZSBhIHBhcnRpY3VsYXIg ZGlyZWN0b3J5LA0KKyAgICogYW5kIGl0IGRvZXNuJ3QgYXZvaWQgdGhlIHJh Y2UgY29uZGl0aW9uLiAgQnV0IHZvbHVtZV9pbyB1c2VkIGl0IGZvcg0KKyAg ICogeWVhcnMsIHNvIEkgc2VlIG5vIHJlYXNvbiB0byBkaXNhbGxvdyB0aGlz IGNhc2UgZm9yIHN5c3RlbXMgdGhhdCANCisgICAqIG1pZ2h0IG5vdCBkZWZp bmUgdGhlIGFib3ZlIHR3byBmdW5jdGlvbnMgKHdoZXRoZXIgYW55IHN1Y2gg c3lzdGVtcw0KKyAgICogZXhpc3QgaXMgdW5jbGVhciB0byBtZSkuDQorICAg Ki8NCisgIHRtcGZpbGVfcHRyID0gbWFsbG9jKExfdG1wbmFtICsgMSk7DQor ICBpZiAodG1wZmlsZV9wdHIgIT0gTlVMTCkgew0KKyAgICBpZiAodG1wbmFt KHRtcGZpbGVfcHRyKSA9PSBOVUxMKSB7DQorICAgICAgZnJlZSh0bXBmaWxl X3B0cik7DQorICAgICAgdG1wZmlsZV9wdHIgPSBOVUxMOw0KKyAgICB9DQor ICAgIGVsc2Ugew0KKyAgICAgIHRtcF9mZCA9IG9wZW4odG1wZmlsZV9wdHIs IE9fQ1JFQVQgfCBPX0VYQ0wgfCBPX1JEV1IsDQorCQkgICAgU19JV1JJVEUg fCBTX0lSRUFEKTsgLyogQ3JlYXRlIHRoZSBmaWxlLiAqLw0KKyAgICB9DQor ICB9DQorDQorI2Vsc2UNCisjZXJyb3IgIlN5c3RlbSBkZWZpbmVzIG5laXRo ZXIgbWtzdGVtcCgpLCB0ZW1wbmFtKCksIG5vciB0bXBuYW0oKSINCisjZW5k aWYgLyogTmVpdGhlciBIQVZFX01LU1RFTVAsIEhBVkVfVEVNUE5BTSwgb3Ig SEFWRV9UTVBOQU0gZGVmaW5lZC4gKi8NCisNCisgIC8qIElmIHdlIGdldCBo ZXJlLCB0bXBfZmQgc2hvdWxkIGhhdmUgYmVlbiBvcGVuZWQgYW5kIHRoZSBm aWxlDQorICAgKiBjcmVhdGVkLiAgTm93IGdvIGFoZWFkIGFuZCBjbG9zZSB0 aGUgZmlsZS4NCisgICAqLw0KKyAgaWYgKHRtcF9mZCA+PSAwKSB7DQorICAg IGNsb3NlKHRtcF9mZCk7DQorICB9DQorICBlbHNlIHsNCisgICAgZnJlZSh0 bXBmaWxlX3B0cik7DQorICAgIHRtcGZpbGVfcHRyID0gTlVMTDsNCisgIH0N CisgIHJldHVybiAodG1wZmlsZV9wdHIpOw0KIH0NCg0KSW5kZXg6IHZvbHVt ZV9pby9Qcm9nX3V0aWxzL2ZpbGVzLmMNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NClJDUyBmaWxlOiAvc29mdHdhcmUvc291cmNlL21pbmMvY3Zzcm9vdC9t aW5jL3ZvbHVtZV9pby9Qcm9nX3V0aWxzL2ZpbGVzLmMsdg0KcmV0cmlldmlu ZyByZXZpc2lvbiAxLjM3DQpkaWZmIC11IC1yMS4zNyBmaWxlcy5jDQotLS0g dm9sdW1lX2lvL1Byb2dfdXRpbHMvZmlsZXMuYwkxMyBTZXAgMjAwMCAxNDoz MjoyNiAtMDAwMAkxLjM3DQorKysgdm9sdW1lX2lvL1Byb2dfdXRpbHMvZmls ZXMuYwkxMSBNYXIgMjAwMyAxODowNDo0MyAtMDAwMA0KQEAgLTgwNSwxMSAr ODA1LDcgQEANCiANCiBwdWJsaWMgIFNUUklORyAgZ2V0X3RlbXBvcmFyeV9m aWxlbmFtZSggdm9pZCApDQogew0KLSAgICBjaGFyICAgICB0bXBfbmFtZVtM X3RtcG5hbSsxXTsNCi0NCi0gICAgKHZvaWQpIHRtcG5hbSggdG1wX25hbWUg KTsNCi0NCi0gICAgcmV0dXJuKCBjcmVhdGVfc3RyaW5nKCB0bXBfbmFtZSAp ICk7DQorICAgIHJldHVybiBtaWNyZWF0ZV90ZW1wZmlsZSgpOw0KIH0NCiAN CiAvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBNTkkgSGVhZGVy IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpAQCAtODM1 LDcgKzgzMSw3IEBADQogew0KICAgICBTdGF0dXMgICBzdGF0dXM7DQogICAg IGludCAgICAgIGk7DQotICAgIGNoYXIgICAgIHRtcF9uYW1lW0xfdG1wbmFt KzFdOw0KKyAgICBjaGFyICAgICAqdG1wX25hbWU7DQogICAgIGNoYXIgICAg IGNvbW1hbmRbRVhUUkVNRUxZX0xBUkdFX1NUUklOR19TSVpFXTsNCiAgICAg U1RSSU5HICAgYWNjZXNzX3N0ciwgZXhwYW5kZWQ7DQogICAgIEJPT0xFQU4g IGd6aXBwZWQ7DQpAQCAtODk1LDcgKzg5MSw3IEBADQogICAgIHsNCiAgICAg ICAgIC8qIC0tLSB1bmNvbXByZXNzIHRvIGEgdGVtcG9yYXJ5IGZpbGUgKi8N CiANCi0gICAgICAgICh2b2lkKSB0bXBuYW0oIHRtcF9uYW1lICk7DQorICAg ICAgICB0bXBfbmFtZSA9IGdldF90ZW1wb3JhcnlfZmlsZW5hbWUoKTsNCiAN CiAgICAgICAgICh2b2lkKSBzcHJpbnRmKCBjb21tYW5kLCAiZ3VuemlwIC1j ICVzID4gJXMiLCBleHBhbmRlZCwgdG1wX25hbWUgKTsNCiAgICAgICAgIGNv bW1hbmRfc3RhdHVzID0gc3lzdGVtKCBjb21tYW5kICk7DQpAQCAtOTE2LDYg KzkxMiw4IEBADQogICAgICAgICB9DQogICAgICAgICBlbHNlDQogICAgICAg ICAgICAgcmVwbGFjZV9zdHJpbmcoICZleHBhbmRlZCwgY3JlYXRlX3N0cmlu Zyh0bXBfbmFtZSkgKTsNCisNCisgICAgICAgIGZyZWUodG1wX25hbWUpOw0K ICAgICB9DQogDQogICAgIC8qIC0tLSBmaW5hbGx5LCBvcGVuIHRoZSBmaWxl ICovDQoNCkluZGV4OiB2b2x1bWVfaW8vVm9sdW1lcy92b2x1bWVfY2FjaGUu Yw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9zb2Z0d2Fy ZS9zb3VyY2UvbWluYy9jdnNyb290L21pbmMvdm9sdW1lX2lvL1ZvbHVtZXMv dm9sdW1lX2NhY2hlLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjI1DQpk aWZmIC11IC1yMS4yNSB2b2x1bWVfY2FjaGUuYw0KLS0tIHZvbHVtZV9pby9W b2x1bWVzL3ZvbHVtZV9jYWNoZS5jCTE3IE1heSAxOTk2IDE5OjM2OjIzIC0w MDAwCTEuMjUNCisrKyB2b2x1bWVfaW8vVm9sdW1lcy92b2x1bWVfY2FjaGUu YwkxMSBNYXIgMjAwMyAxODowNTo0OCAtMDAwMA0KQEAgLTg2MCw3ICs4NjAs NiBAQA0KICAgICBpbnQgICAgICAgIG91dF9zaXplc1tNQVhfRElNRU5TSU9O U10sIHZvbF9zaXplc1tNQVhfRElNRU5TSU9OU107DQogICAgIFJlYWwgICAg ICAgbWluX3ZhbHVlLCBtYXhfdmFsdWU7DQogICAgIE1pbmNfZmlsZSAgb3V0 X21pbmNfZmlsZTsNCi0gICAgY2hhciAgICAgICB0bXBfbmFtZVtMX3RtcG5h bSsxXTsNCiAgICAgU1RSSU5HICAgICAqdm9sX2RpbV9uYW1lczsNCiAgICAg U1RSSU5HICAgICAqb3V0X2RpbV9uYW1lcywgb3V0cHV0X2ZpbGVuYW1lOw0K IA0KQEAgLTg3MSw5ICs4NzAsNyBAQA0KICAgICBpZiggc3RyaW5nX2xlbmd0 aCggY2FjaGUtPm91dHB1dF9maWxlbmFtZSApID09IDAgKQ0KICAgICB7DQog ICAgICAgICBjYWNoZS0+d3JpdGluZ190b190ZW1wX2ZpbGUgPSBUUlVFOw0K LSAgICAgICAgKHZvaWQpIHRtcG5hbSggdG1wX25hbWUgKTsNCi0gICAgICAg IG91dHB1dF9maWxlbmFtZSA9IGNvbmNhdF9zdHJpbmdzKCB0bXBfbmFtZSwg Ii4iICk7DQotICAgICAgICBjb25jYXRfdG9fc3RyaW5nKCAmb3V0cHV0X2Zp bGVuYW1lLCBNTkNfRU5ESU5HICk7DQorICAgICAgICBvdXRwdXRfZmlsZW5h bWUgPSBnZXRfdGVtcG9yYXJ5X2ZpbGVuYW1lKCk7DQogDQogICAgICAgICBj YWNoZS0+ZmlsZV9uY19kYXRhX3R5cGUgPSBnZXRfdm9sdW1lX25jX2RhdGFf dHlwZSggdm9sdW1lLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICZjYWNoZS0+ZmlsZV9zaWduZWRfZmxhZyApOw0K ---2066828793-2035456016-1047581660=:8287168-- From minc-development@bic.mni.mcgill.ca Fri Mar 14 02:45:45 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Thu, 13 Mar 2003 21:45:45 -0500 Subject: [MINC-development] Another pass at micreate_tempfile() In-Reply-To: Message-ID: On Thu, 13 Mar 2003, Robert VINCENT wrote: > After a brief hiatus, here is a revised take on the micreate_tempfile() > function for your comments... > > The new version of the function returns a malloc'd string, or NULL on > error. It takes no arguments. 'Looks good. Minor point though - if malloc returns NULL, I think that you will try to free the NULL anyway (farther down, outside the #if, when you test the file descriptor). Rather than setting temp_fd to -1, it would be simpler to just return NULL immediately. There is no cleanup required at that point (memory or descriptors). Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Fri Mar 14 15:03:57 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri, 14 Mar 2003 10:03:57 -0500 Subject: [MINC-development] Another pass at micreate_tempfile() In-Reply-To: Message-ID: On Thu, 13 Mar 2003, Peter NEELIN wrote: > 'Looks good. Minor point though - if malloc returns NULL, I think that you > will try to free the NULL anyway (farther down, outside the #if, when you > test the file descriptor). Rather than setting temp_fd to -1, it would be > simpler to just return NULL immediately. There is no cleanup required at > that point (memory or descriptors). > Oops. Must've drank too much cough syrup. It's fixed now. -bert From minc-development@bic.mni.mcgill.ca Sat Mar 15 02:12:18 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Fri, 14 Mar 2003 21:12:18 -0500 Subject: [MINC-development] NetCDF/HDF5 Proposal Approved (fwd) Message-ID: Interesting developments in the NetCDF/HDF world... ---------- Forwarded message ---------- Date: Fri, 14 Mar 2003 14:54:18 -0700 From: Russ Rew To: netcdfgroup@unidata.ucar.edu Subject: NetCDF/HDF5 Proposal Approved Hi, We're pleased to announce that a joint Unidata/NCSA project "Merging the NetCDF and HDF5 Libraries to Achieve Gains in Performance and Interoperability" was awarded funding under NASA's Advanced Information Systems Technology (AIST) Program: http://www.nasa.gov/HP_news_03101.html The proposed work will create a data access library that preserves desirable common characteristics of netCDF and HDF5 while taking advantage of their separate strengths: the widespread use and simplicity of netCDF and the generality and performance of HDF5. Unidata will collaborate closely with Mike Folk (coPI) and other researchers at the National Center for Supercomputing Applications to develop the new data access library during the next two years. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program russ@unidata.ucar.edu http://my.unidata.ucar.edu From minc-development@bic.mni.mcgill.ca Sat Mar 15 02:28:21 2003 From: minc-development@bic.mni.mcgill.ca (Robert VINCENT) Date: Fri, 14 Mar 2003 21:28:21 -0500 Subject: [MINC-development] NetCDF/HDF5 Proposal Approved (fwd) In-Reply-To: Message-ID: Thanks for forwarding this, Peter. We knew that this was a possibility from our discussions with Russ and Mike. It's difficult to know how much this will help us, although it certainly shouldn't hurt. Their two-year timeframe may be too long for us to plan on relying on NetCDF 4 for NIfTI and other related projects, but perhaps some features (like named dimensions) useful to MINC will get added to HDF5 soon. This seems to cement the idea that as a file format, NetCDF is a dead end. -bert From minc-development@bic.mni.mcgill.ca Tue Mar 25 00:30:07 2003 From: minc-development@bic.mni.mcgill.ca (Colin Holmes) Date: Mon, 24 Mar 2003 16:30:07 -0800 Subject: [MINC-development] MINC format converters Message-ID: Howdy, I'd like to validate a list of minc file format converters currently being collected by the NIH's NIFTI Data Format Working Group. Please take a quick look at the following list of converters and if you know of an addition, please reply to me directly with the following information about it: Input format name: (standard file extension is great too) Output: (just .mnc or is there a minc -> .format? ) URL/ Download site: (where to get it) Development Info: (author?) Dependencies: (needs some other package?) Comments: (whatever you have to say about it) Suggested By: (who you are, email address is fine) I promise to share the augmented list with this group! Known MINC converters & input formats: 3dAFNItoMINC 3dMINCtoAFNI ana2mnc, mnc2ana (UCLA's analyze to minc-ers) analyze<->minc (Oxford FMRIB converters) destominc, minctodes (UTHSCSA's DES to/from MINC) mri_convert (Harvard multiformat interconverter) The LONI Debabler (UCLA LONI multiformat converter) Suspected format converters -- please point me to: STIMULATE <-> MINC VIFF <-> MINC minc <-> 3D Tiff dicom <-> minc : especially minc-to-dicom anything else NIFTI should know about? Thanks a billion, Colin. (minc representative, NIFTI Data Format Working Group) --- Colin J. Holmes, PhD Manager for Scientific Visualization, Mailstop 41-3-405, 1600 Amphitheatre Pkwy, Mountain View CA 94043 USA cholmes@sgi.com (650) 933-7512 fx 933-0819 From minc-development@bic.mni.mcgill.ca Tue Mar 25 01:04:08 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Tue, 25 Mar 2003 11:04:08 +1000 Subject: [MINC-development] MINC format converters In-Reply-To: References: Message-ID: On Mon, 24 Mar 2003, Colin Holmes wrote: > I'd like to validate a list of minc file format > converters currently being collected by the NIH's > NIFTI Data Format Working Group. Please take a quick > look at the following list of converters and if you > know of an addition, please reply to me > directly with the following information about it: > > Input format name: (standard file extension is great too) > Output: (just .mnc or is there a minc -> .format? ) > URL/ Download site: (where to get it) > Development Info: (author?) > Dependencies: (needs some other package?) > Comments: (whatever you have to say about it) > Suggested By: (who you are, email address is fine) ===ana2mnc|mnc2ana|spm2mnc|mnc2spm|ana_show=== Input format name: Analyze Output: .mnc URL/ Download site: http://www.cmr.uq.edu.au/~rotor/software/ Development Info: Andrew Janke (rotor@cmr.uq.edu.au) Dependencies: Perl Comments: has become a bit of a dog. (see below) Suggested By: rotor@cmr.uq.edu.au ===unc2mnc=== Input format name: UNC Output: .mnc URL/ Download site: http://www.cmr.uq.edu.au/~rotor/software/ Development Info: Andrew Janke (rotor@cmr.uq.edu.au) Dependencies: Perl Comments: UNC is of BAMM/XBAMM UCL fame. Suggested By: rotor@cmr.uq.edu.au ===gis2mnc=== Input format name: gis Output: .mnc URL/ Download site: none, mail me if you want it Development Info: Andrew Janke (rotor@cmr.uq.edu.au) Dependencies: Perl Comments: Is largely untested, GIS is the format used anatomist (the sooper-dooper french sulcal identification suite of tools) NB: the french have their own mnc2gis converter that uses volume_io for the conversion. Suggested By: rotor@cmr.uq.edu.au ===mif2mnc=== Input format name: mif4 Output: .mnc URL/ Download site: BIC CVS Development Info: Andrew Janke (rotor@cmr.uq.edu.au) Dependencies: Perl Comments: MIF4 is used/developed by UBC, docco for this converter was kindly provided by Andrew Riddenhough. Suggested By: rotor@cmr.uq.edu.au ===m2f2mnc=== Input format name: m2f Output: .mnc URL/ Download site: BIC CVS Development Info: Louis Collins Dependencies: Perl Comments: M2F is an old format of UBC's Suggested By: rotor@cmr.uq.edu.au ===pvconv=== Input format name: Bruker Paravision Output: .mnc URL/ Download site: http://www.mrc-cbu.cam.ac.uk/Imaging/pvconv_pod.html Development Info: Matthew Brett and Andrew Janke Dependencies: Perl Comments: Bruker "format" of Paravisino ilk. this is primarily a PV->analyze converter with experimental MINC support. (-outtype=minc) Suggested By: rotor@cmr.uq.edu.au There are also of course the siemens/GE/phillips/scx/ecat converters that you would know about already. > Known MINC converters & input formats: > > 3dAFNItoMINC > 3dMINCtoAFNI > ana2mnc, mnc2ana (UCLA's analyze to minc-ers) Interesting.... (got a URL?) I have become quite despondent as of late with "ANALYZE" to minc converters simply because of the veritable plethora of versions of analyze format that appear to exist, and when you add SPM into the mix it just get's even more fun. IMHO SPM "ANALYZE" should die a painfull death. Or at least not purpote itself to be "analyze" which it is not. > Suspected format converters -- please point me to: > > STIMULATE <-> MINC > VIFF <-> MINC > minc <-> 3D Tiff use mincpik. (it uses Imagemagicks convert). > anything else NIFTI should know about? MINC will rule the earth. On this note i have recently began work on a all-singing all-dancing converter myself that will use XML as a base format as per ImageMagicks MIFF. I have not yet found a suitable candidate for the XML DTD but am still searching. The reason being that all the perl converters I have written share a common "$ghdr" object that could very easily become XML. Best part is netcdf XML converters already exist, eg: an example converted header from a MINC file: http://www.cmr.uq.edu.au/~rotor/graagh/foo.xml Of course WRT XML there is always http://imlib3d.sourceforge.net/ This library supports an XML datatype so currently I am tending towards it's internal format as a base DTD. I'll be very interested to know the results/outcome of your little group. -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Tue Mar 25 15:43:12 2003 From: minc-development@bic.mni.mcgill.ca (Rick Hoge) Date: Tue, 25 Mar 2003 10:43:12 -0500 Subject: [MINC-development] MINC format converters In-Reply-To: Message-ID: <7C56E84E-5ED8-11D7-9D0D-000393B3ACC6@nmr.mgh.harvard.edu> Hi Colin, Here's another converter > Input format name: Dicom (including Siemens Syngo mosaic; > Output: a directory containing all generated .mnc files > URL/ Download site: > http://www.nmr.mgh.harvard.edu/~rhoge/minc/dist/mgh-dicom.tar.gz > Development Info: derived from Peter Neelin's Acr_Nema libs, > dicomserver by Rick Hoge > Dependencies: binary can run standalone > Comments: has a bug where it won't convert a single file; binaries for Linux, Irix, and Mac OSC avail > Suggested By: > > I promise to share the augmented list with this group! > > Known MINC converters & input formats: > > 3dAFNItoMINC > 3dMINCtoAFNI > ana2mnc, mnc2ana (UCLA's analyze to minc-ers) > analyze<->minc (Oxford FMRIB converters) > destominc, minctodes (UTHSCSA's DES to/from MINC) > mri_convert (Harvard multiformat interconverter) > The LONI Debabler (UCLA LONI multiformat converter) > > Suspected format converters -- please point me to: > > STIMULATE <-> MINC > VIFF <-> MINC > minc <-> 3D Tiff > dicom <-> minc : especially minc-to-dicom > > anything else NIFTI should know about? > > Thanks a billion, > Colin. > (minc representative, NIFTI Data Format Working Group) > --- > Colin J. Holmes, PhD > Manager for Scientific Visualization, > Mailstop 41-3-405, 1600 Amphitheatre Pkwy, > Mountain View CA 94043 USA > cholmes@sgi.com (650) 933-7512 fx 933-0819 > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > ______________________________________ Richard D. Hoge, Ph.D. Instructor, HMS Department of Radiology A. A. Martinos Center for Biomedical Imaging 149 13th St. Charlestown MA 02129 phone 617-726-6598 fax 617-726-7422 ______________________________________ From minc-development@bic.mni.mcgill.ca Wed Mar 26 03:18:45 2003 From: minc-development@bic.mni.mcgill.ca (Peter NEELIN) Date: Tue, 25 Mar 2003 22:18:45 -0500 Subject: [MINC-development] MINC format converters In-Reply-To: Message-ID: On Tue, 25 Mar 2003, Andrew Janke wrote: > There are also of course the siemens/GE/phillips/scx/ecat converters that you > would know about already. Unfortunately, the Siemens, GE, Philips converters were (and I suspect still are) developed under NDA and the perl code exposes proprietary information that those companies at one point cared about keeping quiet (goodness knows why), so they cannot be freely distributed. The Scanditronix and ECAT converters do not have this problem, as far as I understand. There is a dicom_to_minc perl script in the same spot that could be useful: Input format name: DICOM Output: .mnc URL/ Download site: http://www.bic.mni.mcgill.ca/~neelin/distrib/minc_converters/dicom/ Development Info: Peter Neelin Dependencies: minc, perl, libacr_nema (same directory), image_filters (required source files in same directory, full package at MNI minc ftp site) Comments: Based on an old perl script hack, but produces reasonably good MINC files for anatomical MRI. Preserves standard DICOM fields from the first DICOM file in the minc header. Suggested By: neelin@bic.mni.mcgill.ca Peter ---- Peter Neelin (neelin@bic.mni.mcgill.ca) From minc-development@bic.mni.mcgill.ca Wed Mar 26 03:22:41 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Wed, 26 Mar 2003 13:22:41 +1000 Subject: [MINC-development] MINC format converters In-Reply-To: References: Message-ID: On Tue, 25 Mar 2003, Peter NEELIN wrote: > > There are also of course the siemens/GE/phillips/scx/ecat converters that you > > would know about already. > > Unfortunately, the Siemens, GE, Philips converters were (and I suspect > still are) developed under NDA and the perl code exposes proprietary > information that those companies at one point cared about keeping quiet > (goodness knows why), so they cannot be freely distributed. The > Scanditronix and ECAT converters do not have this problem, as far as I > understand. > > There is a dicom_to_minc perl script in the same spot that could > be useful: > > Input format name: DICOM > Output: .mnc > URL/ Download site: http://www.bic.mni.mcgill.ca/~neelin/distrib/minc_converters/dicom/ > Development Info: Peter Neelin > Dependencies: minc, perl, libacr_nema (same directory), > image_filters (required source files in same > directory, full package at MNI minc ftp site) > Comments: Based on an old perl script hack, but produces > reasonably good MINC files for anatomical MRI. > Preserves standard DICOM fields from the > first DICOM file in the minc header. > Suggested By: neelin@bic.mni.mcgill.ca > > Peter > ---- > Peter Neelin (neelin@bic.mni.mcgill.ca) > > > > _______________________________________________ > MINC-development mailing list > MINC-development@bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042 From minc-development@bic.mni.mcgill.ca Mon Mar 31 05:14:47 2003 From: minc-development@bic.mni.mcgill.ca (Andrew Janke) Date: Mon, 31 Mar 2003 15:14:47 +1000 Subject: [MINC-development] param2xfm && xfm2param Message-ID: $ param2xfm -scales 1 -1 1 t2.xfm $ cat t2.xfm MNI Transform File %Mon Mar 31 15:08:50 2003>>> param2xfm -scales 1 -1 1 t2.xfm %(Package MNI AutoReg, version 0.98k, compiled by rotor@twodogs.cmr.uq.edu.au (mips-sgi-irix6.5) on 2002-09-06 at 12:02:54) Transform_Type = Linear; Linear_Transform = 1 0 0 0 0 -1 0 0 0 0 1 0; so far so good. $ xfm2param t2.xfm after parameter extraction -center 0.00000 0.00000 0.00000 -translation 0.00000 0.00000 0.00000 -rotation 0.00000 0.00000 0.00000 -scale 1.00000 1.00000 1.00000 -shear 0.00000 0.00000 0.00000 Hrm..? -- Andrew Janke ( rotor@cmr.uq.edu.au || www.cmr.uq.edu.au/~rotor ) Australia->University of Queensland->Centre for Magnetic Resonance Work: +61 7 3365 4100 || Home: +61 7 3800 4042