I was going to suggest directly logging in as “root” to see if that gave you access, because all of the “permissions” doesn’t necessary mean “all” – some things only want to talk to “root”, rather than checking permissions.
]]>I’ve reinstalled the backup and restore app and opened one of the backup folders in the restore app. Everything looks just as it should: the right files were backed up (if anything was), etc. So why can’t I see the folders themselves and their contents? (No, they’re not hidden. And the messages are about permissions.) If I don’t get a reply on the forums… it seems less and less likely… I’ll try copying the backups to another drive (if I have permissions) and experimenting with them there. This is really tiresome!
]]>Does it give a read on file permissions? The permission on the directory should start with a d followed by 9 more characters. drwxrwxrwx would mean that anyone can do anything with the directory. Hyphens means you can’t do something [read, write, execute].
]]>I thought I’d found the fix on a SourceForge forum, a snippet of Python source code which, if replaced in the backup-config app, would fix a bug with deciding which old backups to delete before proceeding to new backups. The broken code basically deleted… nothing. But alas, the fix was in 🙂 … the fix was already applied to the sources distributed with this version, and I’ve seen no basis to believe the source and the distributed build are out of sync.
There is one other thing I may have screwed up on: my backup directory was a descendant of Documents, which itself gets backed up; perhaps the s/w isn’t smart enough to catch and avoid the circular reference. Hey, I’m learning a lot! 🙂
]]>You aren’t trying to do this through the GUI? I’m not sure what that sees, but they should be accessible from the command line.
]]>(OT, those big files I mentioned may be in a Windows format of some sort. Whatever… if I can’t see ’em, I can’t delete ’em. And uninstalling/reinstalling the s/w didn’t get rid of ’em.)
]]>