Bring the Catalog to the next level...

[jacky]

Yes, I expected something like this... it's a dirty solution... needs some meditation...

Or you simply don't use the drive letter only, but some (configurable) prefixes, like "Drive C" or "Backup of Server ServerName" ?

[admin]

Yes, I expected something like this... it's a dirty solution... needs some meditation...

Or you simply don't use the drive letter only, but some (configurable) prefixes, like "Drive C" or "Backup of Server ServerName" ?

Yep, that would be a solution. But they should not be so long, because this kind of storage method can easily hit the 260 char limit. Also, they rather should not be configurable, because else you'd break old backups (break = XY can not auto-derive the original soruce location from the target anymore).

[jacky]

Yep, that would be a solution. But they should not be so long, because this kind of storage method can easily hit the 260 char limit. Also, they rather should not be configurable, because else you'd break old backups (break = XY can not auto-derive the original soruce location from the target anymore).

Well, I realized the configurable part could "break" things indeed, I even consider putting "tweakable" instead, cause what I intened by that was to give the use a choice - at first.

So you could use nothing for drive letters, and "@" for servers, but if someone already uses the @ in his own names, it could change it to something else...

Thinking of it though, I'm not sure I see the problem with what jc said. So what if you get this :
C:\backups\@server\share\@folder\subfolder

XY would see this as two possibilities for restore :
\\server\share\@folder\subfolder
\\folder\subfolder

Isn't that pretty much the same as what you described earlier, with MY Documents\D\Temp\C\Program Files\XYplorer\ ?

[j_c_hallgren]

Thinking of it though, I'm not sure I see the problem with what jc said.

I was only pointing out that some of us use the "@" already, so if that had some special XY meaning, it may be a conflict...I wasn't saying it would be an issue, but just wanted to mention it, just in case.

[admin]

Yep, that would be a solution. But they should not be so long, because this kind of storage method can easily hit the 260 char limit. Also, they rather should not be configurable, because else you'd break old backups (break = XY can not auto-derive the original soruce location from the target anymore).

Well, I realized the configurable part could "break" things indeed, I even consider putting "tweakable" instead, cause what I intened by that was to give the use a choice - at first.

So you could use nothing for drive letters, and "@" for servers, but if someone already uses the @ in his own names, it could change it to something else...

Thinking of it though, I'm not sure I see the problem with what jc said. So what if you get this :
C:\backups\@server\share\@folder\subfolder

XY would see this as two possibilities for restore :
\\server\share\@folder\subfolder
\\folder\subfolder

Isn't that pretty much the same as what you described earlier, with MY Documents\D\Temp\C\Program Files\XYplorer\ ?

Yes, it would work. On further meditation I'd prefer to prefix something to the drive-folders as well, because it is quite likely that people use one-letter folders for organizing data. I don't want to upset them...

So currently I see this as a working solution (d_ for drive, s_ for server):

Source: C:\MyData\
Target: D:\backup\
Result: D:\backup\d_C\MyData\

Source: \\Computer\MyData\
Target: D:\backup\
Result: D:\backup\s_Computer\MyData\

It's also visually standing out quite nicely.

There would also be a further distant option to prefix "r_" for relative:

Source: C:\MyData\
Target: D:\backup\
Result: D:\backup\r_MyData\folder\thefile.txt

That would restore relative to some location. But which location? Well, maybe a prompt for the user: select location to "restore" (it's a simple copy operation of course) MyData\folder\thefile.txt to. It would then create the necessary subfolders (MyData\folder\) below that location. Well, maybe I'm drifting away...

[graham]

admin wrote:

Well, maybe I'm drifting away...

Just think of it as an undo called restore

[PeterH]

Sorry: maybe i'm gonna write rubbish? But possibly it's worth thinking about it...

On one side there are possible problems with names of backedup files getting (too) long.
On the other side there could be problems with (maybe accidently) changing the structure of backup-directories. (Especially, as only a part of the name shows, that this is a backup-directory.)

A possible solution could be not to store backup to a real directory-hierarchy, but to a virtual one, to a sort of 'container', as an .iso, .zip or something alike. One advantage would be a new level of names *inside* the container, the other, that modifications *inside* a container could only be made by "utility", not by any simple filemgr-function. (I.e.: you are aware, that you are *inside* the container!)
(And: maybe the container could use compression...)

[admin]

Sorry: maybe i'm gonna write rubbish? But possibly it's worth thinking about it...

On one side there are possible problems with names of backedup files getting (too) long.
On the other side there could be problems with (maybe accidently) changing the structure of backup-directories. (Especially, as only a part of the name shows, that this is a backup-directory.)

A possible solution could be not to store backup to a real directory-hierarchy, but to a virtual one, to a sort of 'container', as an .iso, .zip or something alike. One advantage would be a new level of names *inside* the container, the other, that modifications *inside* a container could only be made by "utility", not by any simple filemgr-function. (I.e.: you are aware, that you are *inside* the container!)
(And: maybe the container could use compression...)

I understand, but:
(1) XY does not attempt to replace your backup software. As always, I want to keep things straight and simple. XY's backup is a user-friendly, easy-to-understand way to quickly take snapshots of work-in-progress data. It has its limits.
(2) I personally dislike zipped backups because their lack of redundancy (one byte changed due to a bad HD sector, and the whole zip is garbage), and their dependency on unzipping software. I feel very comfortable with "open" (unzipped) backups, even if they take lots of space and may run into name length issues (I keep my names short).