malformed base path in GetVolumeEntry

This is just a guess, but does the name of your TM volume include spaces or any non-alphanumeric characters?

Check out this thread. I made a post that fixed the problem. It has been going on for a cople of months and decided to fix it since I just got a new time machine and transferred by backups to it. In my case I didn't remove the file but edited it. Maybe something in the defaults is causing it in those two plist keys.

http://discussions.apple.com/thread/3071050

So are you saying there may be paths in the Time Machine exclude list that are no longer valid, and that is what causes the error? If so, could it just be cleaned up with Time Machine (deleting the no-longer-valid exclude paths)?

Or that the exclude list itself has become damaged, and must be discarded and rebuilt?

I dug into it a little deeper. I restored the my previous /Library/Preferences/com.apple.TimeMachine.plist file and got those errrors again. I was able to pin point what exactly was causing them. I had two paths causing the problem. The others even if they no longer exists did not. The entries are in the key "ExcludeByPath" in the plist. I don't see anyway to make changes to the entries from any preference panel. The exclusions from the Time Machine preferences are in the "SkipPaths" key. The two entries are:

"./.flexlmrc"

"./.flexlmborrow"

The path says to use the current directory(./) so I can see why it would cause errors. So to answer your questions directly...there are paths in the Time Machine exclude list that are invalid. They can be cleaned up but by editing the file. You do not have to discard the list itself.

You can use defaults in the Terminal app to edit the file. You can view the list by:
defaults read /Library/Preferences/com.apple.TimeMachine

It's been a while since the post, Duc, so I hope that yo u're still monitoring it.

I can easily get to the information in Terminal, but once there I'm not 100% sure what to do. I'm having the same problem, of course with the "malformed base path...".

Thanks in advance.

"do a cd" = type command?

And the entire command should be:

</Library/Preferences/sudo chmod a+w com.apple.TimeMachine.plist sudo open com.apple.TimeMachine.plist> as one string?

Thanks.

cd is change-directory, the argument is what directory to change to, and if it begins with /, start at top-level:

cd /Library/Preferences/

... takes you to top-level, then down to the explicitly-named directory.

You can also type cd and then drag-and-drop the directory from a Finder window, and the command will be completed with the Finder Directory path. Press return and Terminal executes the command you built.

sudo is a separate command, asking to be treated as the Super-User, which you can be after typing your password (which will not be echoed) then the chmod command will be executed as if you were the Super-User. Chmod is used to change the permissions of the file so it can be modified.

As a casual user of these tools, I vastly prefer to use PropertyListEditor.app instead of these Terminal commands.

@Duc Phuc - thanks for this post! It is great to learn more about Time Machine configuration, and its issues.

@astropig - the .flexlmrc directory can be found if the home directory of any account that has run the FlexLM license manager. This license manager is used by a variety of applications to handle license adminstration. I'm familiar with its use for IDL, PGI (Portland Group) Fortran compiler, and Matlab. I suspect there are others....

I'm not sure how these ".flexlm*" are being entered into the TimeMachine.plist file - I suspect it is from the IDL installer. There are also a number of entries for ".flexlm*" in several of my Macports paths. The problem with the paths displayed by Duc Phuc is that they are relative paths, rather than fully qualified paths.

Parallels apparently will put a number of paths, to its virtual machines, into the com.apple.TimeMachine.plist file.

cheers,

Roy 🙂

Hi Grant,

isn't the problem that without using the sudo command to give write permissions to other accounts, the GUI of choice, either PropertyEditor or Xcode, will not be able to save modifications to the file?

one needs to use some mechanism to allow group or everyone write privileges, at least temporarily. I've used the Get Info interface over many OS versions to do such, and this often results in a mixed bag of permission changes. Use of command line utilities, such as chmod, work correctly, everytime. Of course, one must provide the proper "instructions" by using the proper syntax.

one of the things I love about Mac OS X is that it provides both GUI and command line methods for almost any task, allowing users to mix and match, according to their individual tastes!

okay, I'll get off my soapbox..... 😉

cheers,

Roy

Roy Miller-

isn't the problem that without using the sudo command to give write permissions to other accounts, the GUI of choice, either PropertyEditor or Xcode, will not be able to save modifications to the file?

You are quite right. In this case, you need the SuperUser privileges to write those parameters, and would be forced to use command-line tools.

My statement was my preference -- I rarely get to use it. Writers who are command-line jockeys tend to publish the command-line procedures.

I find defaults write completely confusing, and it seems dangerous. Where you are writing is never very clear to me. I much prefer the context of the Property List Editor files and the re-assurance that you are editing in the correct place, and creating well-formed parameters.

no worries Grant, and I hope I didn't offend - definitely not my intention!

Hi Grant,

I'm lucky enough to enjoy both GUI and command-line interfaces, and am always exploring which method of manipulation works better for me for a given task.

for example, I really prefer Finder for viewing and organizing my folder and file hierarchy, and also have experienced that when deleting a folder/directory with tens or hundreds of thousands of files, that the "rm" command is much, much speadier than dragging the folder to the trash and emptying in Finder.

one advantage I've stumbled across in using the "defaults write" command is when adding a new configuration entry to an application config file (plist file usually? always?). If one is lucky enough to find where someone has published a "defaults write" command somewhere on the web, I can add the functionality. For example, using the "focus follows mouse" ability in Terminal is a long-time favorite of mine, but if someone hadn't published it on the web, I'd never have known the syntax myself, for either "defaults write" or PropertyEditor!

my biggest gripe about "defaults write" and the plist files that it modifies is that there is no "dictionary" of available "hooks". I used to script with AppleScript a lot for a while, and really liked the AppleScript Dictionary required to be included in each Mac application.

ahhh, I'm beginning to taste the soap again! or is it Cool-Aid?

cheers,
Roy