Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About TheBum

  • Rank
    Frequent Poster
  1. Another possibility may be to use a selector for a folder (NOT an enclosing folder) whose path is /usr/share/swupd/html. A folder selector is supposed to skip backing up subdirectories whereas an enclosing folder selector is supposed to recursively include subdirectories.
  2. I'm not sure, but I think Retrospect skips compressing files that are already compressed, such as JPEGs (with some compression algorithms, attempting to compress an already compressed file will actually create a larger file). Even if it does compress them, it's lossless as Lennart said.
  3. Maybe there's a conflict between QT 7.0.4 and Norton AV 8.0.4. Did you try uninstalling Norton AV? It's mostly superfluous anyway.
  4. Why? Are you seeing any? I haven't updated my PowerBook yet so it'd be nice to know of any potential gotchas.
  5. Too late. I already sent it. It was only 256 KB so it shouldn't cause any problems.
  6. My sincerest thanks. Now if Dantz could only fix the problem with pitond dying, which has also been reported here by more than one person.
  7. As far as I know, they haven't even acknowledged it yet, despite the fact that myself and at least one other person have posted detailed logs pertaining to the issue. Dantz is historically slow at fixing bugs, so I wouldn't count on a fix soon.
  8. Quote: OSX 10.3.9 PowerBook G4 1.25GHz Retrospect Client 6.1.107 and Retrospect Windows Multi-server 6.5.350 I recently updated client to 6.1 from 6.0; backups are done by a PC server running multi server 6.5. PC clients still do and I used to get a confirmation dialog before the Proactive backup was about to start. The prefs in MS are to give a 99 second countdown before starting. Since installing client 6.1 I no longer see this dialog. Can anyone confirm this? It's a known issue with the 6.1 Mac client. See this thread.
  9. Any more ideas as to what might be causing this? In the meantime, it appears that I'll have to either settle for the current behavior or yank out one of the drives and install it in an external case.
  10. Quote: Now that I think about it, I'm being backed up over my wired Ethernet connection, but I sometimes have a wireless connection active as well. I wonder if that is related? Alan is your setup similar? I always do my backups wirelessly.
  11. I did not check whether a scan was in progress. Were you checking that on the server side or the client side?
  12. Many thanks. I'll post back with any findings. I'm a Unix software developer by trade, so I enjoy a good code mystery but only if I have the tools to find the clues. [update] I ran pitond with a log level of 9 and discovered that the problem appears to be the closing of a file handle that was never opened (at least according to the debug info). The crash appears to happen in a function called NetCancelSockets when the machine starts going to sleep. Here's the last part of the log: 1132287973: NetCancelSockets: wait cancelling sockets 1132287973: NetCancelSockets: cancelling socket 9 1132287973: connAccept: Handle 9 closed 1132287973: connAccept: close(socket) failed with error 9 1132287973: Assertion failure at pitond/object.c-477 1132287973: LogFlush: program exit(-1) called, flushing log file to disk There are a number of "connAccept: Handle <x> closed" messages in the log, each of which has a corresponding "TransStart: Handle <x> start" message preceding it at some point. Handle 9 is an exception; there is no corresponding TransStart message. Hope this helps with the diagnosis. I'll keep checking to see if future crashes involve the same file handle. [Yet another update] The next time it happened was with a different file handle. The only consistencies are that it's always happening inside NetCancelSockets and that it always involves a file handle being closed that was apparently never opened.
  13. Let me start the diagnosis by saying that the error 9 on the close() call indicates a bad file descriptor. So, either a file descriptor is being closed twice or memory is being "stepped on", causing a corrupt file descriptor. It would help to have a version of pitond that outputs more debug info, such as the value of the file descriptor in the failed close() call.
  14. No luck. I didn't actually physically inspect the jumpers, but here's what Apple System Profiler says (unit number emphasis added): Quote: PIONEER DVD-RW DVR-104: Model: PIONEER DVD-RW DVR-104 Revision: A227 Serial Number: MBGDL197938WL Detachable Drive: No Protocol: ATAPI Unit Number: 0 Socket Type: Internal PIONEER DVD-RW DVR-107D: Model: PIONEER DVD-RW DVR-107D Revision: 1.21 Detachable Drive: No Protocol: ATAPI Unit Number: 1 Socket Type: Internal However, both drives show up in Retrospect with an ID of ATAPI-A:0:0. Shouldn't Retrospect be getting the unit number from the same place as Apple System Profiler does?
  15. I'll check this evening (I'm 99% sure I got the master/slave jumpers correct), but wouldn't that cause one or both of the drives not to work? They both work perfectly other than the Retrospect issue.