Please, may I ask you to either provided the trace and job log as requested. As I can argue that we are using 2019 to 2022 with 0% of your troubles
That kind of guerilla can be endless. If we have traces, joblog fileset etc we may have a chance to reproduce. If it is reproducible, then there's a chance to have a fix. If we can elaborate that fix, you may have a chance to solve your trouble. Le mercredi 17 janvier 2024 à 09:58:19 UTC+1, jo.go...@hosted-power.com a écrit : > I just tried > https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe > > on Windows 2022. But I still have 100's of failed in use files :/ > > On Wednesday 17 January 2024 at 09:49:10 UTC+1 Spadajspadaj wrote: > >> Hi Bruno. >> >> Yes, I understand how it's supposed to work. :-) >> >> OK, I will re-run the tests when I have a spare minute and dump the trace >> somewhere (the excerpt I posted earlier was with debug level 999 so all >> messages should have been captured). >> >> And it's not that I _thought_ it wasn't backed up. I know it wasn't >> backed up. It was throwing errors of being unable to access the file and if >> I wanted to restore the files I got a zero-length content. I know it should >> have been converted to the shadowcopy-based filename but wasn't. >> >> I'll check the latest package version first though. >> >> MK >> On 17.01.2024 09:43, Bruno Friedmann (bruno-at-bareos) wrote: >> >> To add an illustration to the fact that BareOS works as documented and >> expected. >> We run a backup job while the registry hive is open in regedit and we >> tried to remove it so you get the expected error, the file is in use. >> >> In the background you can see the success of the job backing up that file >> without any error. >> See the details about the status of VSS BackupComplete. >> >> [image: thumb-Screenshots_43.png] >> >> Le mercredi 17 janvier 2024 à 09:34:37 UTC+1, Bruno Friedmann >> (bruno-at-bareos) a écrit : >> >>> Hi Spadapjspadaj, >>> >>> When we examine what happen on test machine here we see it working >>> correctly. >>> Especially that the VSS is present. >>> >>> you may think we don't backup the snapshot due to the presence of >>> *C:/Users/user/NTUSER.dat* in the log, but you need to understand that >>> is the resulting file name after its conversion in compact.cc >>> compat/compat.cc:555-307 Leave >>> make_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\user\NTUSER.dat >>> compat/compat.cc:1609-307 sizino=8 ino=0 filename=C:/Users/user/NTUSER.dat >>> desktop-vcf7e32-fd (300): findlib/find_one.cc:911-307 File ----: C:/ >>> Users/user/NTUSER.dat desktop-vcf7e32-fd (130): filed/backup.cc:535-307 >>> FT_REG saving: C:/Users/user/NTUSER.dat desktop-vcf7e32-fd (130): >>> filed/backup.cc:646-307 >>> filed: sending C:/Users/user/NTUSER.dat to stored >>> So to be sure we use the same code, could you please install and run the >>> following bareos-fd >>> >>> https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe >>> >>> In your director you set the debug level to 500 for that client >>> (changing the client name in the following example) >>> >>> setdebug level=500 trace=1 timestamp=1 client=windows-fd >>> >>> this will indicate where the tracelog will be written (often directly on >>> C:\) >>> run one backup job then disable the debugging, >>> To extract in text mode the joblog in bconsole >>> @out /tmp/backup-win-fd.joblog >>> list joblog jobid=XXXXX >>> q >>> >>> Then you can zip and attach both trace and joblog here. >>> Add the fileset used too. >>> >>> BTW please ensure your fileset contain >>> Enable VSS = yes >>> as stated in documentation and Windows fileset example. >>> >>> Le mardi 16 janvier 2024 à 15:38:37 UTC+1, Spadajspadaj a écrit : >>> >>> I used the relatively new available client. (23-pre-something, >>> downloaded around 2 weeks ago). Yes, I should have written that explicitly. >>> On 16.01.2024 15:23, Bruno Friedmann (bruno-at-bareos) wrote: >>> >>> Hello, all normally the issues that are described here, should have been >>> already fixed, and should work without any trouble with bareos >= 23 >>> >>> The code fixing the problem has been submitted and merge a certain time >>> ago with PR1452 >>> https://github.com/bareos/bareos/pull/1452 >>> >>> Please refresh your installation, and of course report success and >>> failures. >>> >>> Le jeudi 11 janvier 2024 à 23:17:26 UTC+1, Spadajspadaj a écrit : >>> >>> As I understand, this is the interesting excerpt from the debug trace. >>> >>> win10test-fd (50): findlib/find.cc:169-0 Verify=<V> Accurate=<Cmcs> >>> BaseJob=<Jspug5> flags=<724185736> >>> win10test-fd (50): findlib/find.cc:169-0 Verify=<V> Accurate=<Cmcs> >>> BaseJob=<Jspug5> flags=<724185736> >>> win10test-fd (450): findlib/find.cc:175-0 F C:/Users/test/NTUSER.DAT >>> win10test-fd (500): compat/compat.cc:278-0 Enter >>> convert_unix_to_win32_path >>> win10test-fd (500): compat/compat.cc:322-0 path = >>> \\?\C:\Users\test\NTUSER.DAT >>> win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path >>> path=\\?\C:\Users\test\NTUSER.DAT >>> win10test-fd (500): compat/compat.cc:234-0 Win32ConvInitCache: Setup of >>> thread specific cache at address 1532b2b76d0 >>> win10test-fd (500): compat/compat.cc:531-0 Enter make_wchar_win32_path >>> win10test-fd (500): compat/compat.cc:555-0 Leave >>> make_wchar_win32_path=\\?\C:\Users\test\NTUSER.DAT >>> win10test-fd (500): compat/compat.cc:1609-0 sizino=8 ino=0 >>> filename=C:/Users/test/NTUSER.DAT >>> win10test-fd (300): findlib/find_one.cc:911-0 File ----: >>> C:/Users/test/NTUSER.DAT >>> win10test-fd (130): filed/backup.cc:535-0 FT_REG saving: >>> C:/Users/test/NTUSER.DAT >>> win10test-fd (130): filed/backup.cc:646-0 filed: sending >>> C:/Users/test/NTUSER.DAT to stored >>> win10test-fd (150): lib/crypto_openssl.cc:641-0 crypto_digest_new >>> jcr=1532b228410 >>> win10test-fd (300): filed/backup.cc:1575-0 encode_and_send_attrs >>> fname=C:/Users/test/NTUSER.DAT >>> win10test-fd (500): compat/compat.cc:278-0 Enter >>> convert_unix_to_win32_path >>> win10test-fd (500): compat/compat.cc:322-0 path = >>> \\?\C:\Users\test\NTUSER.DAT >>> win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path >>> path=\\?\C:\Users\test\NTUSER.DAT >>> win10test-fd (300): filed/backup.cc:1594-0 File C:/Users/test/NTUSER.DAT >>> attribs=A A IH/ B A A CAi FAAA A A BlnTaz BlnTaz BlnTaz A A L >>> attribsEx=CAi HaQkZzohoU HaQvQ8Q7yY HaQvQ8Q7yY A FAAA >>> win10test-fd (300): filed/backup.cc:1620-0 >stored: attrhdr 1 5 >>> 0win10test-fd (200): filed/backup.cc:1772-0 No strip for >>> C:/Users/test/NTUSER.DAT >>> win10test-fd (300): filed/backup.cc:1715-0 >stored: attr len=130: 1 3 >>> C:/Users/test/NTUSER.DAT >>> win10test-fd (150): filed/backup.cc:737-0 type=3 do_read=1 >>> win10test-fd (100): findlib/bfile.cc:710-0 bopen: fname >>> C:/Users/test/NTUSER.DAT, flags 00100000, mode 0000, rdev 8226 >>> win10test-fd (50): findlib/bfile.cc:565-0 === NO plugin >>> win10test-fd (100): findlib/bfile.cc:664-0 Read >>> CreateFileW=\\?\C:\Users\test\NTUSER.DAT >>> win10test-fd (850): lib/message.cc:1216-0 Enter Jmsg type=8 >>> win10test-fd (850): lib/message.cc:613-0 Enter DispatchMessage type=8 >>> msg=win10test-fd JobId 16959: Cannot open "C:/Users/test/NTUSER.DAT": >>> ERR=The process cannot access the file because it is being used by another >>> process. >>> . >>> win10test-fd (850): lib/message.cc:820-0 DIRECTOR for following msg: >>> win10test-fd JobId 16959: Cannot open "C:/Users/test/NTUSER.DAT": >>> ERR=The process cannot access the file because it is being used by another >>> process. >>> . >>> win10test-fd (400): findlib/find_one.cc:493-0 FT_REG FI=1 linked=0 >>> file=C:/Users/test/NTUSER.DAT >>> >>> From what I understand from the description of the >>> make_wchar_win32_path() method in win32/compat/compat.cc - we should leave >>> the function with the filename properly converted to VSS-based one. But >>> apparently we're stuck with local name. >>> >>> MK >>> On 11.01.2024 22:03, Spadajspadaj wrote: >>> >>> The more I dig into it, the more it seems it is bareos after all. >>> >>> Unfortunately, building Windows bareos-fd is no small feat so I cannot >>> directly debug it but. >>> >>> I ran a procmon against bareos-fd.exe and it seems that while the FD >>> process does create a VSS snapshot... it doesn't read from it. It reads the >>> files straight from the main device. I did a small test fileset consisting >>> of just my user's registry file. And both procmon's dump as well as >>> bareos-fd own debug trace shows that it's trying to read simply a >>> c:\users\test\ntuser.dat instead of properly going for >>> \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopyXX\Users\test\ntuser.dat. >>> That would explain why the job even though it's supposed to use VSS, fails >>> on copying open files. >>> >>> When I created a very small example VS project just creating a VSS >>> snapshot and copying said file out of the VSS snapshot (using the proper >>> shadow copy volume path), it works OK. >>> >>> MK >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "bareos-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to bareos-users...@googlegroups.com. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/bareos-users/9bb76105-597b-4cb9-b5b5-95f54e5b96e6n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/bareos-users/9bb76105-597b-4cb9-b5b5-95f54e5b96e6n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to bareos-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/30b4adee-5fe4-44dc-8f63-e63eb803fd5dn%40googlegroups.com.
