#1 Linux file date not preserved

[Ron Schnatzmeyer]

Thank you for picking this product up again. I've been using areca since 2015, I'm glad someone is supporting it again.

I am using the current Linux Mint, and "OpenJDK Runtime Environment (build 21.0.7+6-Ubuntu-0ubuntu124.04)". I am backing up to an external USB formatted ext4, no encryption. Something has happened so that the Linux file date modified is not being preserved. This is happening on both version 7.5 and 8. It used to be, if I restored something, it would restore with the original date modified stamp that was on the file when it was backed up. But now the restored file is being created new, with current date stamps. This is really bad. If you restore a file you want the file characteristics preserved.
I had to a full restore about a year ago, due to a crash, and the date modified restored intact. Now it isn't.
I don't see any options that control this, and I don't know where else look so I thought I'd open a ticket here.

[Bugtamer]

Hi,

Yes, it's fine to open tickets here.

Test environment

• OS: Linux Mint
• JDK: OpenJDK 1.8 Temurin
• Areca: 8.2.4 (version 8 has only superficial changes compared to 7.5 so far — they even have the same old dependencies)

I restored a single file, messages.txt, it both to a USB partition and to my desktop.

I ran three recovers from the GUI (none from the TUI) to check consistency, from:

• Archive detail (Archives tab >> right-click on an archive >> Archive detail... >> Archive content)
• Logical view
• Logical view - File history

From the Search tab, one of the above views is opened.

Results

It seems that Areca uses the File date ( in File history) as the modification date rather than the creation date. Is this what you were referring to when you mentioned a date issue? I'm not questioning it, I just want to make sure I'm understanding you correctly. The attached image shows more details to confirm we're talking about the same thing.

I need to study what metadata Areca actually stores about the files, especially regarding the date(s), and avoid making assumptions before changing anything. I believe that aside from the archive itself, it saves metadata in a file called trace (csv format), and I think it only stores a single date — I'm not sure whether it also uses the file dates from the archive.

Best regards,
bugtamer

[Ron Schnatzmeyer]

Hello,

Thank you for the reply. Here is some testing I have done.
I selected a single file with which to work and is old enough that do not really need it.

The file as created looks like this, the Access date is updated by the backup.

stat QData-2025-06-12*
  File: QData-2025-06-12.AM09.03.QDF-backup
  Size: 80465920    Blocks: 157168     IO Block: 4096   regular file
Device: 259,1   Inode: 37266049    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/     ron)   Gid: ( 1000/     ron)
Access: 2025-07-08 03:10:15.527034144 -0500
Modify: 2025-06-12 09:03:52.000000000 -0500
Change: 2025-06-12 09:03:50.565293283 -0500
 Birth: 2025-06-12 09:03:50.521293969 -0500

I renamed this file by adding 'save' to end. That updated the Change stamp, but not the Modify stamp.

stat QData-2025-06-12*
  File: QData-2025-06-12.AM09.03.QDF-backup-save
  Size: 80465920    Blocks: 157168     IO Block: 4096   regular file
Device: 259,1   Inode: 37266049    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/     ron)   Gid: ( 1000/     ron)
Access: 2025-07-08 03:10:15.527034144 -0500
Modify: 2025-06-12 09:03:52.000000000 -0500
Change: 2025-07-09 16:03:25.731453424 -0500
 Birth: 2025-06-12 09:03:50.521293969 -0500

Then I restored the original file from the backup. Archives > Archives Detail > Archives Content > Right click on the file I want to recover >
click Recover. In the location box is /home/ron. I select "Always override existing files". I do not want to recover in the separate subdirectory shown /home/ron/rcv0,
I want it restored to its original directory. The restored file looks like this - all the dates are the same:

stat QData-2025-06-12*
  File: QData-2025-06-12.AM09.03.QDF-backup
  Size: 80465920    Blocks: 157168     IO Block: 4096   regular file
Device: 259,1   Inode: 37224909    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/     ron)   Gid: ( 1000/     ron)
Access: 2025-07-09 16:09:27.507797952 -0500
Modify: 2025-07-09 16:09:27.079804628 -0500
Change: 2025-07-09 16:09:27.079804628 -0500
 Birth: 2025-07-09 16:09:25.389830989 -0500

But...after testing with this a couple of days, I think I see what is happening. When it gets to the step of applying the metadata, which I believe is what sets the date stamps to what they are supposed to be, the program crashes. It appears to be trying to apply metadata to every file in the whole /home/ron directory instead of just the one restored file. I looks like it is crashing
when it hits some files it can't access. I included a log copy as an attachment. I am guessing it hits enough errors that it just dies.

Note In the warnings "Xeoma.desktop" is part of my home security software. Discover-Magazine are symbolic links in a WINE appication that point to things like /dev/ttyS0. I don't know it is even trying to touch those files.

So far, that's what I have discovered. Thanks for your help. Ron

[Bugtamer]

Hi,

TL;DR The date issue isn't a bug, it seems to be a feature. The second issue about applying metadata to each file in the directory does seem to be a bug. So I'll focus on the 2nd bug.

Given its age, Areca uses java.io.File (among other custom/helper classes) to represent or interact with files, and this class only supports the last modified date. I haven't seen any of those custom classes yet that handle other date types.

Given its age, Areca uses java.io.File (among other custom/helper classes) to represent or interact with files, and this class only supports the last modification date. I haven't seen any of those custom classes yet that handle other date types. Added to this is the fact that Areca only stores a single timestamp in the traces, reinforcing the idea that it only handles a single date as metadata.

I'd say fixing this would be a major change, and without sufficient automated testing, it's a change that can't be implemented quickly. Note: import java.io.File; has 180 matches.

There are other Java classes that allow you to manage, for example, the creation date. I'll need some time to delve into how to best address this in the existing codebase. I have some ideas, but I need to weigh them.

So, for now, unless I see a viable simple strategy for dates, I'll focus first on the second error, which, on paper, seems more manageable.

Regards,
bugtamer

[Ron Schnatzmeyer]

OK, based on information from what you said above, I did some more digging and testing and I think there is really only one problem which is how it applies the metadata.

Looking at these dates from the linux stat command:

File: some-old-test-file.txt
  Size: 38903       Blocks: 80         IO Block: 4096   regular file
Device: 259,1   Inode: 36996580    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/     ron)   Gid: ( 1000/     ron)
Access: 2025-07-08 03:35:53.878485019 -0500
Modify: 2025-01-21 12:51:50.843453962 -0600
Change: 2025-01-21 21:15:58.591284887 -0600
 Birth: 2025-01-21 21:15:58.587284963 -0600

"Access" is the last time the file was read.
"Change" refers to updates to file name, permissions etc.
"Birth" is when the file was originally created.

Since the backup itself has to read the file in order to back it up, there is probably no reason save the Access date. "Change" and "Birth" could be considered nice-to-have, or even not-wanted in some cases. So there is probably no need to worry about them either.

It is the "Modify" date that is critical on a restore. If I have to restore, for example, '/home/ron/Documents', I need the correct last modified date on the file. So let's focus on that.

**What areca is currently doing to manage this Modify date, does appear to be working correctly. **

In my case, I am losing the Modify date on some restores because the program is crashing before it can apply that date to the restored file. And it is crashing because it appears to be trying to apply this metadata to the whole '/home/ron' directory instead of just the restored file. It crashes because some of the files are symbolic links that it cannot access. Note, I am not backing up symbolic links. So why it is trying to apply the metadata to the whole directory is the issue.

The problem appears to originate from this attached screen.
Using this example, the original file was backed up from '/home/ron/QBACKUP/QData-2025-06-21.AM07.51.QDF-backup'

If I run the restore using the pre-selected option "Recover in a sub-directory (/home/ron/rcv1), areca will restore the file, apply the Modify date and not crash. The file will be located in '/home/ron/rcv1/QBACKUP/QData-2025-06-21.AM07.51.QDF-backup'. But then I have to manually move the file to where it is supposed be. That's not too bad if there is only one file, but if there are hundreds of restored files that must go into different directory locations, it's a pain.

If I change the restore location shown to be '/home/ron/QBACKUP', the restored file(s) end up in '/home/ron/QBACKUP/QBACKUP/'. That's not good either.

So I usually select "Always override existing files". In that case, it will put the restored files where they belong. But, this is where it will then start applying the metadata to the whole directory and in my case, crashes. Probably because it is using the location '/home/ron' on the screen instead of the location it restored the file(s) to.

So after some digging, testing and discussion, I hope that clarifies the situation a little better.

I have been using Areca since 2015. Thank you again picking up this really great backup software that is so easy to use, does exactly what I need, and has features no other program has.

[Bugtamer]

Hi.
After several tests, I've reproduced your error, but only when there's a symlink in the archive from which a file is retrieved; if there's no symlink, there's no error, as far as I've been able to test.

There is a comment that says "Last modification date and mode. They are not set on symlinks (not supported)" within setMetaData() for JNIMetaDataAccessor.java but it "works" for DefaultMetaDataAccessor.java (without ACL support) so ends with a warning but the files are recovered with the last modified date that had when they were backup:

YY-MM-DD HH:MM - WARNING - Error executing {chmod, 51864, /home/ron/test_dir2/subdir/e2.txt} : chmod: invalid mode: ‘51864’

I'm just mentioning this as feedback; I'm still pending to implement a fix.
Regards.

[Bugtamer]

Hi,

Let's take it one step at a time:

There are two types of recoveries:

1. Simple recovery of a specific version of a file
2. Full recovery of an entire archive

Each of these opens the same recovery window but with different options but under the same window title, and with no distinction as to the purpose (!). The simple recovery has Location and Check content of recovered files, while the full recovery has those same fields and some additional ones. The image you shared corresponds to a full recovery, which is why the messages appeared for multiple files.

Regarding the errors that appear, it is due to the lack of sufficient permissions when running Areca to change the metadata of files that have a different user/group than the one running Areca. At least, in my tests, I saw this behavior; those that shared the user and group worked fine.

So, running Areca with a user who can use sudo allowed me to perform the full recovery without errors, with the correct dates, user, and group as initially stored (the trace file contains this information; it is compressed and in a format similar to csv). In my tests, there were files belonging to different users and also a symlink.

Linux GUI Example

• $ sudo ./areca.sh

Pay attention because the loaded workspace may change to /root/.areca/workspace.

CLI Example

• $ sudo ./bin/areca_cl.sh recover -config /home/USER/.areca/workspace/1234567890.bcfg -c -destination /home/USER/your-destination-directory

To view Areca CLI help:

• $ ./bin/areca_cl.sh
• areca_cl.bat (for Windows)

I hope these instructions solve your problem and can serve as a reference for future users.

Regards.

[Ron Schnatzmeyer]

First, thanks for taking the time and effort to help resolve this issue. Here are some thoughts after working through this.

There is a third type of recovery.
That type is: Recovery of a specific version of a entire subdirectory. This is not a full recovery nor just a single file. When I need to restore something, this is often the one I need.

From the Logical View tab you can only select the most recent backup of a directory, not a version on an older archive. Right click the directory > Recover > This will open the Full Recovery screen.

If you want to recover an entire directory from an older archive, you have to:
Go to Archives Tab >
Double click the specific backup archive you want which opens the Archive Detail screen, OR, right click on the backup archive and select Archive Detail from the drop down. >
then click Archive Content >
In Archive Content find the directory you want to restore and right click on it which opens the Full Recovery screen.

On the Full Recovery screen:
The default location populated on my screen is '/home/ron'. If you select any option other than the first one "Recover in subdirectory /home/ron/rcv", it will recover only the specific directory you want, but it will go on to apply metadata to every directory and file under the Location field '/home/ron'.

This is the root of the problem of it applying metadata to directories totally unrelated to the restore and causing the permissions crashes. It seems to me if I just recover directory XYZ, it should know to only apply metadata to directory XYZ. But you have to change this Location field to '/home/ron/XYZ' as well so it doesn't hit the whole home directory.

So I guess the best solution is to simply let it restore to '/home/ron/rcv' and manually move the restored directory afterward. Because then it only applies the metadata to the recovered directory.

Thanks

[Bugtamer]

Now that you mention recovering a folder, I also remember that you can arbitrarily restore files and folders if you select/deselect them while holding down the Control key, and this can be done both in the Archive detail and the Logical view.

I was only able to reproduce your issue when the original files and folders were overwritten by the restored ones and the restoration required elevating Areca’s privileges using sudo to make changes (for example: read-only destination, a different user/group than the one being applied, etc.). Without elevated privileges, it failed in those cases. On Linux, for instance, Areca internally uses chown / lchown to change user/group ownership.

Can you confirm whether using sudo works or not in the following scenarios?

1. Restoring a single file (simple recovery)
2. Restoring an entire archive (full recovery)
3. Restoring more than one file but less than an archive (partial recovery)

You can test this on a new target with irrelevant data.

I’ve just verified all three cases successfully, making the restore operation require user/group or read-only changes, using sudo.

I need to narrow down the issue. I can’t move forward until I’ve completely ruled out privilege escalation. If it still doesn’t work after that, I’ll need to be able to reproduce your error again in order to help.

I assume you have tried it, but I prefer an explicit mention before looking for other options that can reproduce your problem.

Regards

[Bugtamer]

Since I haven't received any further messages, I understand the issue is closed with the advice provided above. If not, feel free to reopen the issue.

Regards