Bugtamer

Hi Manfred, I dedicate some of my free time to the Areca project, and I've been busy lately. So, sorry for not replying for so long. I remember that editing the XML and removing _e worked in tests on my local machine. Regarding the location of the files (configurations and archives), it's probably not relevant. It is worth noting, however, that it's preferable not to overwrite one version of Areca with another, especially to avoid overwriting areca/config/fwk.properties, which contains ACL preferences...

Hi Stefan, It occurs to me that working in a Unix-like environment might have caused a problem with ACL permissions, something that wouldn't happen in Windows; either with read or write permissions (as applicable). Areca's ACL support needs to be compatible with the system it's trying to read from or write to, and it also needs to have sufficient permissions to do so. You can check if any ACL errors appear in the Log panel when you start Areca. If so, there's specific help for troubleshooting these...

Hi Artur, In theory, you should be able to decompress the data, but its metadata (creation dates, read-only access, ACLs, etc. - I don't recall if the path is also considered metadata) might not be fully recoverable due to the missing folders. In my experience as a user (I'm not the original developer), I seem to recall having to decompress the archives twice in some specific cases to extract the original files. Areca includes an "external" decompression and decryption tool for these types of operations,...

Hi Manfred, 1) On the new PC, are the archives in the same location as on the old one? 2) I understand you've already tried opening the workspace. - Menu "Workspace" - Option "Open workspace...". 3) Have you tried importing the *.bcfg files (modified or not)? - Menu "Workspace" - Option "Import...". 4) Do any error or warning messages appear in the logs? Regards.

Hi Philip, Yes, I think it's as you indicate, something to be prepared for in the near future. From what I've been able to find out, it seems that a new parameter (e.g., java --enable-native-access=ALL-UNNAMED [...] or anything more specific than ALL-UNNAMED) will need to be added to the launchers (areca_run.bat and areca_run.sh), but I haven't been able to test it to confirm since I haven't been able to reproduce the message. Could you tell me: Operating system (I've tested both Windows and Linux)...

WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning

Hi Philip, Yes, I think it's as you indicate, something to be prepared for in the near future. From what I've been able to find out, it seems that a new parameter (e.g., java --enable-native-access=ALL-UNNAMED [...] or anything more specific than ALL-UNNAMED) will need to be added to the launchers (areca_run.bat and areca_run.sh), but I haven't been able to test it to confirm since I haven't been able to reproduce the message. Could you tell me: Operating system (I've tried both Windows and Linux)...

Linux file date not preserved