really weird move file problem

  • Hi folks,

    Very strange scenario: I'm modifying .mov files at the Atom level,
    then moving the modded file out of /tmp and into user space with ...

    NSAssert([[NSFileManager defaultManager] movePath:workingFilePath
                                                        toPath:[self
    resultFilePath]
                                                      handler: nil],
    @"could not move the media file");

    On a certain machine, when moving to a second partition, or a
    connected firewire device, the file move freaks out and just runs and
    runs and runs, with no errors thrown. There is a tmp file in the
    final location (the usual "ADFSDL-DUDTYDSHSO" type generated name). I
    have to force quit my app. The resulting file is, of course,
    unusable. There are no errors in the log. If I select a location on
    the same partition for the final file, the move works fine.

    At this point, it only appears to happen on one machine -- a MacBook
    Pro with HFS+ using GUID partition table. (However, code works fine
    on my MacBook Pro with the same formatting)

    Can anyone think of possible reasons for this? Any way of
    troubleshooting? I'm stumped.

    Jaime Magiera
    Sensory Research
    http://www.sensoryresearch.net
  • > Can anyone think of possible reasons for this? Any way of
    > troubleshooting? I'm stumped.

      Have you tried the obvious first? Namely, have you (using Disk
    Utility or some other tool) checked the volume(s) in question for
    errors?

    --
    I.S.
  • On Sep 21, 2007, at 12:17 PM, Emanuele ° Vulcano wrote:
    >
    > Since it doesn't seem that your code is the culprit at first
    > glance, I'd first make sure it's not an outside problem -- check
    > the target disk with Disk Utility first.

    On Sep 21, 2007, at 12:25 PM, I. Savant wrote:
    > Have you tried the obvious first? Namely, have you (using Disk
    > Utility or some other tool) checked the volume(s) in question for
    > errors?

    Yes, the user told me he re-formatted the drive with the same result
    and is going to do so again now to be sure all errors are gone.

    However, disk error would be strange if copying to the same partition
    works fine, but copying to a different partition *OR* an external
    firewire drive doesn't work. Hmmmm.

    Jaime Magiera
    Sensory Research
    http://www.sensoryresearch.net
  • On 9/21/07, Jaime Magiera <jaime...> wrote:
    > Yes, the user told me he re-formatted the drive with the same result
    > and is going to do so again now to be sure all errors are gone.

      Reformatting != checking for errors. That's just blowing away
    current errors. There's no guarantee there isn't a bus problem or some
    other issue causing random faulty writes / reads. That, however,
    should show up in the logs, I believe. You'd just have to know how to
    recognize it when it does.

    > However, disk error would be strange if copying to the same partition
    > works fine, but copying to a different partition *OR* an external
    > firewire drive doesn't work. Hmmmm.

      If you can't reproduce the failure with a similar setup, I'm betting
    it's a user hardware issue. Especially if you have a fair-sized user
    base (a few thousand is "safe enough") and no other reports of similar
    problems.

    --
    I.S.
  • On Sep 21, 2007, at 1:07 PM, I. Savant wrote:

    > Reformatting != checking for errors. That's just blowing away
    > current errors. There's no guarantee there isn't a bus problem or some
    > other issue causing random faulty writes / reads. That, however,
    > should show up in the logs, I believe. You'd just have to know how to
    > recognize it when it does.

    Ok, will do.

    > If you can't reproduce the failure with a similar setup, I'm betting
    > it's a user hardware issue. Especially if you have a fair-sized user
    > base (a few thousand is "safe enough") and no other reports of similar
    > problems.

    The user says this problem exists on another laptop in his
    possession. So, it seems there are now two datapoints.

    I did a special build using copy instead of move. Interestingly, the
    process still failed for him. However, this time, the destination
    file did have the proper name and some data. The process still hung
    though.

    Man, this is driving me nuts. Now, I'm new to byte level programming.
    Is there anything in the endian-ness of files that can affect copying/
    moving?

    Jaime Magiera
    Sensory Research
    http://www.sensoryresearch.net
  • Is there anything weird about the destination file pathname? Unusual characters? Spaces?

    Does it happen with files of any size?

    On Friday, September 21, 2007, at 12:11PM, "Jaime Magiera" <jaime...> wrote:
    > Hi folks,
    >
    > Very strange scenario: I'm modifying .mov files at the Atom level,
    > then moving the modded file out of /tmp and into user space with ...
    >
    > NSAssert([[NSFileManager defaultManager] movePath:workingFilePath
    > toPath:[self
    > resultFilePath]
    > handler: nil],
    > @"could not move the media file");
    >
    >
    > On a certain machine, when moving to a second partition, or a
    > connected firewire device, the file move freaks out and just runs and
    > runs and runs, with no errors thrown. There is a tmp file in the
    > final location (the usual "ADFSDL-DUDTYDSHSO" type generated name). I
    > have to force quit my app. The resulting file is, of course,
    > unusable. There are no errors in the log. If I select a location on
    > the same partition for the final file, the move works fine.
    >
    > At this point, it only appears to happen on one machine -- a MacBook
    > Pro with HFS+ using GUID partition table. (However, code works fine
    > on my MacBook Pro with the same formatting)
    >
    > Can anyone think of possible reasons for this? Any way of
    > troubleshooting? I'm stumped.
    >
    > Jaime Magiera
    > Sensory Research
    > http://www.sensoryresearch.net
    >
    >
  • Jaime ,

    This sounds to me like it could be something completely unrelated to
    the file itself. The fact that your application hangs makes it sound
    like you could be running up against a lurking memory corruption/
    invalid object bug or something that just happens to get triggered at
    this time. Or maybe your paths are invalid. (Check the value coming
    back from resultFilePath before making the call.)

    If that value isn't the problem, I'd rule out the file copy itself by
    putting the code early on into your launch (like awakeFromNib:), and
    using static path strings pointing to a copy of the problem movie and
    the output path:

    - (void) awakeFromNib
    {
    ...
    NSAssert([[NSFileManager defaultManager]
             movePath: @"/ProblemFile.mov"
             toPath: @"ProblemFileOut.mov" handler: nil],
             @"could not move the media file");
    ...
    }

    If the copy functions like that, then there's something else going
    on, which seems likely. If the move fails, it shouldn't be able to
    hang your app. That indicates something else is going on.

    - Dave

    On Sep 21, 2007, at 2:03 PM, Jon Hendry wrote:

    >
    > Is there anything weird about the destination file pathname?
    > Unusual characters? Spaces?
    >
    > Does it happen with files of any size?
    >
    > On Friday, September 21, 2007, at 12:11PM, "Jaime Magiera"
    > <jaime...> wrote:
    >> Hi folks,
    >>
    >> Very strange scenario: I'm modifying .mov files at the Atom level,
    >> then moving the modded file out of /tmp and into user space with ...
    >>
    >> NSAssert([[NSFileManager defaultManager] movePath:workingFilePath
    >> toPath:[self
    >> resultFilePath]
    >> handler: nil],
    >> @"could not move the media file");
    >>
    >>
    >> On a certain machine, when moving to a second partition, or a
    >> connected firewire device, the file move freaks out and just runs and
    >> runs and runs, with no errors thrown. There is a tmp file in the
    >> final location (the usual "ADFSDL-DUDTYDSHSO" type generated name). I
    >> have to force quit my app. The resulting file is, of course,
    >> unusable. There are no errors in the log. If I select a location on
    >> the same partition for the final file, the move works fine.
    >>
    >> At this point, it only appears to happen on one machine -- a MacBook
    >> Pro with HFS+ using GUID partition table. (However, code works fine
    >> on my MacBook Pro with the same formatting)
    >>
    >> Can anyone think of possible reasons for this? Any way of
    >> troubleshooting? I'm stumped.
    >>
    >> Jaime Magiera
    >> Sensory Research
    >> http://www.sensoryresearch.net
    >>
    >>

  • shot in the dark: any "peculiar" characters in the paths? Can you
    move the file from the command line? In the Finder?

    Does the failure occur if you don't modify the file? If you don't
    even open it?

    _murat

    On Sep 21, 2007, at 11:03 AM, Jon Hendry wrote:

    >
    > Is there anything weird about the destination file pathname?
    > Unusual characters? Spaces?
    >
    > Does it happen with files of any size?
    >
    > On Friday, September 21, 2007, at 12:11PM, "Jaime Magiera"
    > <jaime...> wrote:
    >> Hi folks,
    >>
    >> Very strange scenario: I'm modifying .mov files at the Atom level,
    >> then moving the modded file out of /tmp and into user space with ...
    >>
    >> NSAssert([[NSFileManager defaultManager] movePath:workingFilePath
    >> toPath:[self
    >> resultFilePath]
    >> handler: nil],
    >> @"could not move the media file");
    >>
    >>
    >> On a certain machine, when moving to a second partition, or a
    >> connected firewire device, the file move freaks out and just runs and
    >> runs and runs, with no errors thrown. There is a tmp file in the
    >> final location (the usual "ADFSDL-DUDTYDSHSO" type generated name). I
    >> have to force quit my app. The resulting file is, of course,
    >> unusable. There are no errors in the log. If I select a location on
    >> the same partition for the final file, the move works fine.
    >>
    >> At this point, it only appears to happen on one machine -- a MacBook
    >> Pro with HFS+ using GUID partition table. (However, code works fine
    >> on my MacBook Pro with the same formatting)
    >>
    >> Can anyone think of possible reasons for this? Any way of
    >> troubleshooting? I'm stumped.
    >>
    >> Jaime Magiera
    >> Sensory Research
    >> http://www.sensoryresearch.net
    >>
    >>

  • On 9/21/07, Jon Hendry <jonhendry...> wrote:
    >
    > Is there anything weird about the destination file pathname? Unusual characters? Spaces?

      A *very* salient point! Perhaps if you send the user a "debug"
    version that logs the paths before attempting to use them, then have
    the user send you the results, something may jump out at you.

    --
    I.S.
  • > The user says this problem exists on another laptop in his
    > possession. So, it seems there are now two datapoints.

      Ah - then it's rather improbable there's a hardware issue. See the
    others' comments about the validity of the paths themselves.

    --
    I.S.
  • In line with the 'weird character' problems, what language is your
    user using (e.g. Chinese)?  Can the user send you a copy of the file
    in question to play with, or is this consistent regardless of the
    file?  Can you send the user files to test with?

    Good luck,
    Cem Karan
  • On Sep 21, 2007, at 3:23 PM, I. Savant wrote:
    > Ah - then it's rather improbable there's a hardware issue. See the
    > others' comments about the validity of the paths themselves.

    Yeah.

    I have been keeping track of the paths. They are correct and have no
    special characters (that was one of the first things I had him do,
    was make sure all the paths involved had no special characters). Now,
    since the file is partially getting created in the destination
    location, wouldn't that preclude paths as an issue though?

    Here's a weird thing: I met up with him to be sure of what was going
    on. When he tried to use the software in front of me, it could *not*
    copy even to the same partition. So, it doesn't seem to copy to any
    partition or device. We tried setting the destination to my laptop in
    target disk mode. Same error. I ran the software from my machine and
    set the file destination to be *his* laptop in target disk mode. That
    worked fine. We both have the same MacBook Pros (though he has his /
    Users on a separate partition).

    Here's how I'm going to troubleshoot this evening...

    I've just given him a build that has the method modifying the file
    commented out. In other words, it's just going to copy from tmp out
    to his selected destination. This will tell me  unequivocally if it's
    just the copying, or if its something in copying *after* the method
    modifies the file (the method adds a QT Track atom and adds data to
    the MDAT atom).  Note that the method works on all the other machines
    I've tried. The movies play fine with all the right data. crazy.

    I'll keep you folks abreast of the situation as it develops.

    thanks!!!!!

    Jaime Magiera
    Sensory Research
    http://www.sensoryresearch.net
  • Hi,

    On Sep 21, 2007, at 3:36 PM, Cem Karan wrote:

    > In line with the 'weird character' problems, what language is your
    > user using (e.g. Chinese)?

    Nah, he's U.S.

    > Can the user send you a copy of the file in question to play with,
    > or is this consistent regardless of the file?  Can you send the
    > user files to test with?

    In general, the application starts with an m4a file in temp. The app
    then creates a copy for editing, which is also kept in temp ("working
    file"). A method adds some data to the working file. The working file
    is then copied out to user space. The working file in tmp opens fine
    in *all* cases -- even when the copy error happens -- which makes me
    confused. The file opens fine while its in temp, but when I try to
    copy/move it out, the new one doesn't work. <sigh>

    thanks,

    Jaime Magiera
    Sensory Research
    http://www.sensoryresearch.net
  • Sounds like a good first step. Again, if your application is actually
    locking up (per your first message), then this is more than just a
    file manager copy failure (unless the lockup happens later because
    the dest file is invalid or something.) No crash logs, huh?

    If the scaled back version still fails, keep in mind that there could
    still be something more going on that's causing the problem. Is any
    of your code threaded by any chance? That could open entirely new
    possibilities--autorelease pools, calls/code that isn't threadsafe, etc.

    In any case, good luck . :)

    - Dave

    On Sep 21, 2007, at 4:04 PM, Jaime Magiera wrote:

    > On Sep 21, 2007, at 3:23 PM, I. Savant wrote:
    >> Ah - then it's rather improbable there's a hardware issue. See the
    >> others' comments about the validity of the paths themselves.
    >
    > Yeah.
    >
    > I have been keeping track of the paths. They are correct and have
    > no special characters (that was one of the first things I had him
    > do, was make sure all the paths involved had no special
    > characters). Now, since the file is partially getting created in
    > the destination location, wouldn't that preclude paths as an issue
    > though?
    >
    > Here's a weird thing: I met up with him to be sure of what was
    > going on. When he tried to use the software in front of me, it
    > could *not* copy even to the same partition. So, it doesn't seem to
    > copy to any partition or device. We tried setting the destination
    > to my laptop in target disk mode. Same error. I ran the software
    > from my machine and set the file destination to be *his* laptop in
    > target disk mode. That worked fine. We both have the same MacBook
    > Pros (though he has his /Users on a separate partition).
    >
    > Here's how I'm going to troubleshoot this evening...
    >
    > I've just given him a build that has the method modifying the file
    > commented out. In other words, it's just going to copy from tmp out
    > to his selected destination. This will tell me  unequivocally if
    > it's just the copying, or if its something in copying *after* the
    > method modifies the file (the method adds a QT Track atom and adds
    > data to the MDAT atom).  Note that the method works on all the
    > other machines I've tried. The movies play fine with all the right
    > data. crazy.
    >
    > I'll keep you folks abreast of the situation as it develops.
    >
    > thanks!!!!!
    >
    > Jaime Magiera
    > Sensory Research
    > http://www.sensoryresearch.net
  • Can you copy the working file via the command line?

    Can the working file be 'Archived' by the Finder?

    How large is the working file? How much free space is on the destination?

    What is the journaling status of the filesystems?

    How is the working file being modified? I wonder if it is being modified in a way that uses its *own* temp file, which is then copied over the working file, and you're trying to copy the working file in the middle of this process, resulting in a corrupt partial copy.

    Can you add a pause before copying the working file back to user space?

    - Jon

    On Friday, September 21, 2007, at 04:19PM, "Jaime Magiera" <jaime...> wrote:
    > Hi,
    >
    > On Sep 21, 2007, at 3:36 PM, Cem Karan wrote:
    >
    >> In line with the 'weird character' problems, what language is your
    >> user using (e.g. Chinese)?
    >
    > Nah, he's U.S.
    >
    >> Can the user send you a copy of the file in question to play with,
    >> or is this consistent regardless of the file?  Can you send the
    >> user files to test with?
    >
    > In general, the application starts with an m4a file in temp. The app
    > then creates a copy for editing, which is also kept in temp ("working
    > file"). A method adds some data to the working file. The working file
    > is then copied out to user space. The working file in tmp opens fine
    > in *all* cases -- even when the copy error happens -- which makes me
    > confused. The file opens fine while its in temp, but when I try to
    > copy/move it out, the new one doesn't work. <sigh>
    >
    > thanks,
    >
    > Jaime Magiera
    > Sensory Research
    > http://www.sensoryresearch.net
    >
    >
  • Is FileVault active on the machine(s) with the problem?  That can
    cause all manner of weirdness, possibly compounded in this case by
    the unusual setup of having /Users on a separate partition.  In any
    case, I'd also try creating a new user account (with FileVault off of
    course) and see if the problem appears there too.

    Bob S.

    On Sep 21, 2007, at 1:04 PM, Jaime Magiera wrote:

    > On Sep 21, 2007, at 3:23 PM, I. Savant wrote:
    >> Ah - then it's rather improbable there's a hardware issue. See the
    >> others' comments about the validity of the paths themselves.
    >
    > Yeah.
    >
    > I have been keeping track of the paths. They are correct and have
    > no special characters (that was one of the first things I had him
    > do, was make sure all the paths involved had no special
    > characters). Now, since the file is partially getting created in
    > the destination location, wouldn't that preclude paths as an issue
    > though?
    >
    > Here's a weird thing: I met up with him to be sure of what was
    > going on. When he tried to use the software in front of me, it
    > could *not* copy even to the same partition. So, it doesn't seem to
    > copy to any partition or device. We tried setting the destination
    > to my laptop in target disk mode. Same error. I ran the software
    > from my machine and set the file destination to be *his* laptop in
    > target disk mode. That worked fine. We both have the same MacBook
    > Pros (though he has his /Users on a separate partition).
    >
    > Here's how I'm going to troubleshoot this evening...
    >
    > I've just given him a build that has the method modifying the file
    > commented out. In other words, it's just going to copy from tmp out
    > to his selected destination. This will tell me  unequivocally if
    > it's just the copying, or if its something in copying *after* the
    > method modifies the file (the method adds a QT Track atom and adds
    > data to the MDAT atom).  Note that the method works on all the
    > other machines I've tried. The movies play fine with all the right
    > data. crazy.
    >
    > I'll keep you folks abreast of the situation as it develops.
    >
    > thanks!!!!!
    >
    > Jaime Magiera
    > Sensory Research
    > http://www.sensoryresearch.net
  • On 21.09.2007, at 22:16, Jaime Magiera wrote:

    >> In line with the 'weird character' problems, what language is your
    >> user using (e.g. Chinese)?
    >
    > Nah, he's U.S.
    >
    >> Can the user send you a copy of the file in question to play with,
    >> or is this consistent regardless of the file?  Can you send the
    >> user files to test with?
    >
    > In general, the application starts with an m4a file in temp. The
    > app then creates a copy for editing, which is also kept in temp
    > ("working file"). A method adds some data to the working file. The
    > working file is then copied out to user space. The working file in
    > tmp opens fine in *all* cases -- even when the copy error happens
    > -- which makes me confused. The file opens fine while its in temp,
    > but when I try to copy/move it out, the new one doesn't work. <sigh>

      Instead of guessing I'd try to get an Terminal-savy user to measure
    what's going wrong:

    "fs_usage" for disk activity, "sample" for an stacktrace during the
    hang. Both can be piped to an emailable text file.
  • On 21.09.2007, at 22:58, Bob Smith wrote:

    > Is FileVault active on the machine(s) with the problem?  That can
    > cause all manner of weirdness, possibly compounded in this case by
    > the unusual setup of having /Users on a separate partition.  In any
    > case, I'd also try creating a new user account (with FileVault off
    > of course) and see if the problem appears there too.

    .. and of course the other usual suspects:
    - anti-virus software is known for it's habit to interfere with file
    moves and copies while it scans the file.
    - same applies to spotlight, but it shouldn't affect /tmp
  • On 21.09.2007, at 18:08, Jaime Magiera wrote:
    > NSAssert([[NSFileManager defaultManager] movePath:workingFilePath
    > toPath:[self
    > resultFilePath]
    > handler: nil],
    > @"could not move the media file");

      Have you tried specifying a handler and seeing if that gets asked
    for anything interesting? Could any symlinks be involved that might
    cause an infinite loop while copying? What are the permissions of the
    involved files and directories?

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • On Sep 21, 2007, at 4:34 PM, Jon Hendry wrote:

    > Can you add a pause before copying the working file back to user
    > space?

    I added an NSTimer with a long delay to trigger the copy. Problem
    gone. Apparently, the problem was that the method to add bytes to the
    file was returning to the main method, which does to the copy, before
    the NSFileHandle had closed.

    Thanks Jon!

    Jaime Magiera
    Sensory Research
    http://www.sensoryresearch.net
  • On 24 Sep 2007, at 21:36, Jaime Magiera wrote:

    > On Sep 21, 2007, at 4:34 PM, Jon Hendry wrote:
    >
    >> Can you add a pause before copying the working file back to user
    >> space?
    >
    > I added an NSTimer with a long delay to trigger the copy. Problem
    > gone. Apparently, the problem was that the method to add bytes to
    > the file was returning to the main method, which does to the copy,
    > before the NSFileHandle had closed.

    A better solution might be to explicitly send -closeFile to the
    NSFileHandle once you're finished with it... this also has the merit
    that it will work under garbage collection, no matter how long the
    collector decides to wait between collections.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On Sep 24, 2007, at 6:10 PM, Alastair Houghton wrote:

    > A better solution might be to explicitly send -closeFile to the
    > NSFileHandle once you're finished with it... this also has the
    > merit that it will work under garbage collection, no matter how
    > long the collector decides to wait between collections.

    Hi,

    Actually, I did/do. The method uses update for certain parts, then a
    closeFile at the end. For some reason, the closeFile takes longer
    than the method returning to its caller. It seems to be based on the
    amount of bytes written in a particular cycle. For example, when I
    would comment out a part of the method which writes several dozen
    TIFF images to the handle before the closeFile, it copied over fine.
    However, if I un-comment that section, the error returns. So,it seems
    I need to call update more often, or add a delay before the copy. I'm
    curious about two things...

    - Why did my method return before [NSFileHandle closeFile] finishes?
    Would control remain in the call until it returns?

    - What is the caching limit of an NSFileHandle? I would think it
    would be gigabytes. So, why would adding a few TIFF images take such
    a long time to close/update?

    interesting,

    Jaime Magiera
    Sensory Research Network
    http://www.sensoryresearch.net
  • On 25 Sep 2007, at 00:07, Jaime Magiera wrote:

    > - Why did my method return before [NSFileHandle closeFile]
    > finishes? Would control remain in the call until it returns?

    It didn't.  At least, unless you wrote a load of fancy code to
    asynchronously invoke -closeFile.

    > - What is the caching limit of an NSFileHandle?

    There's no such thing.  NSFileHandle is a wrapper around a system
    file handle.  It doesn't have a "caching limit", or any buffering,
    except that provided by the system disk cache (which is below the
    filesystem, so other processes should be able to access data you've
    written almost immediately).

    > I would think it would be gigabytes. So, why would adding a few
    > TIFF images take such a long time to close/update?

    How large are the TIFF images?  What type of disk/filesystem is this
    file on?  Are you using threading at all in this program?  Or are you
    using NSFileHandle's asynchronous methods?  If so, maybe you have a
    race condition of some sort?

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On Sep 25, 2007, at 9:21 AM, Alastair Houghton wrote:

    > It didn't.  At least, unless you wrote a load of fancy code to
    > asynchronously invoke -closeFile.

    Then, I'm even more confused :) Closed means closed, right? If so,
    why the error?

    > There's no such thing.  NSFileHandle is a wrapper around a system
    > file handle.  It doesn't have a "caching limit", or any buffering,
    > except that provided by the system disk cache (which is below the
    > filesystem, so other processes should be able to access data you've
    > written almost immediately).

    OK.

    > How large are the TIFF images?

    I'm sorry, they are actually PNG images of only 8K. They are added in
    a loop and after each is added, synchronizeFile is called (see below).

    > What type of disk/filesystem is this file on?

    These are all HFS+ (many with GUID partition tables).

    > Are you using threading at all in this program?

    Yes, but quite a bit further up the chain. In other words, these
    particular methods are all on the same thread.

    > Or are you using NSFileHandle's asynchronous methods?  If so, maybe
    > you have a race condition of some sort?

    The addImages method is called from the main export method. It is
    passed a NSString for the file path, which shortly into the method is
    used with [NSFileHandle fileForUpdatingAtPath:] to create the handle.
    There are some lines to open the image data into an NSData. That
    NSData is then passed with the file handle to another method
    ("appendData: withfileHandle:") which then appends the data to the
    file and calls [NSFileHandle synchronizeFile] before returning to
    addImages. After the return to addImages, there is creation of some
    smaller chunks of file data (TRAK atom) which is then added to the
    file with a "addAtom: withfileHandle:" method, which also calls
    [NSFileHandle synchronizeFile] (several times actually). After return
    to addImages a second time, [NSFileHandle closeFile] is called.
    addImages then returns to the initial calling method (export), which
    does the copy.

    So, as you can see, I call synchronizeFile and closeFile explicitly
    in the process. I'm not sure what I'm doing wrong in this case.

    Jaime Magiera
    Sensory Research Network
    http://www.sensoryresearch.net
previous month september 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today