File Backups failing for a certain client - "Error writing metadata to file. -1"


#1

Hi,

One of the computers in the cluster is failing to backup since I’ve upgraded the server to v.2.x (from v.1.x). Only one client is failing.

I tried to “start fresh” - reinstall server + clients, reconfigure everything, run full backups - nothing, still the same issue with this particular client.

Here’s what the log have to say:

...
2016-10-09 19:02:25: WARNING: File "\\?\D:\Backup\UrBackup\Certain-PC\161009-1829\.hashes\Documents\<path...>\<...file1>.ZIP" has wrong size. Should=8 is=310. Error writing metadata to file. -1
2016-10-09 19:02:25: ERROR: Error writing file metadata -1
2016-10-09 19:02:25: WARNING: File "\\?\D:\Backup\UrBackup\Certain-PC\161009-1829\.hashes\Documents\<path...>\<...file2>.ZIP" has wrong size. Should=8 is=299. Error writing metadata to file. -1
2016-10-09 19:02:25: ERROR: Error writing file metadata -1
2016-10-09 19:02:25: WARNING: File "\\?\D:\Backup\UrBackup\Certain-PC\161009-1829\.hashes\Documents\<path...>\<...file3>.ZIP" has wrong size. Should=8 is=299. Error writing metadata to file. -1
2016-10-09 19:02:25: ERROR: Error writing file metadata -1
2016-10-09 19:02:26: WARNING: File "\\?\D:\Backup\UrBackup\Certain-PC\161009-1829\.hashes\Documents\<path...>\<...file4>.ZIP" has wrong size. Should=8 is=301. Error writing metadata to file. -1
2016-10-09 19:02:26: ERROR: Error writing file metadata -1
2016-10-09 19:12:12: ERROR: FATAL: Backup failed because of disk problems (see previous messages)
2016-10-09 19:12:15: ERROR: Backup failed

Server Version: v2.0.36
Client Version: v2.0.34
(happened with the previous 2 builds as well, ever since I upgraded the server from v.1.x to v.2.33)

O/S: Windows 10 x64 v.1607

Any clues on how to get rid of this error and continue backing up would be highly appreciated!


#2

Only known issue is name collisions with DOS 8.3 names on Windows.

If that does not help, the best option would be to follow Having problems with UrBackup? Please read before posting – specifically the server log file.


Error starting file metadata download thread
#3

Thanks for the prompt response :slight_smile:
The failing files indeed have DOS-style names, any known workaround?


#4

You are the third (known) person having the problem – so not so rare. I guess, I’ll have to add a hint to the status page or something.


#5

Just read the KB article,

Sadly, the files on my system aren’t OS generated.
They are part of the file structure for “production CDs” that resides on the computer. And 8.3 file names there are required by the target systems CDs are made for, so unfortunately I can’t easily just “get rid of 8.3 filenames” in the system…

I don’t have a clear idea of how complex it would be to patch server to handle those, but I can imagine many scenarios in which people would have 8.3 filenames on their modern systems, and want them backed as well.


#6

You misunderstood, I think. You need to disable 8dot3 name generation on the server, not the client. You can do that per file system and it needs to be done for the UrBackup backup storage file system.


#7

My assumption was that if the source (Client) has it in 8.3 format, the Server PC will copy filenames as they are regardless of 8dot3 name generation setting of its own OS?

If its not the case, I’ll surely test disabling 8dot3 on server system


#8

I’ve tested the suggested workaround - disable 8.3 filenames creation on the server machine, and it worked!

Thanks for your support!