Modified dates are incorrect.

[bibbleskit]

Describe the bug
"Modified date" for images are incorrect on Linux.

To Reproduce
Steps to reproduce the behavior:

1. Look at the properties of any image in OneFolder.
2. Compare the modified dates with the image meta data in another program.

Expected behavior
If the system says the file was last modified "8/12/25", it should display "8/12/25".
Instead, it shows the date it was last changed by OneFolder, I'm assuming.

I added a tag to the image and the modified date updated in OneFolder, as well (but not on the system).

Screenshots
In KDE Gwenview

In OneFolder

OneFolder version

• e.g. v1.1.1

Desktop OS
6.16.3-2-cachyos

Additional context
Add any other context about the problem here.

[Antoine-lb]

Hello @andrensegura

Would you mind to double-check that the modified value is not an OS-specific value?

What I mean is that file systems keep their own "created" and "modified" dates that are not part of the image metadata. We call it the system date, and the one in OneFolder is the metadata date that is stored inside of the image itself.

[bibbleskit]

@Antoine-lb

Here is the stat output for the file:

> stat picrew-concept.jpg
  File: picrew-concept.jpg
  Size: 64721           Blocks: 128        IO Block: 4096   regular file
Device: 8,2     Inode: 161961      Links: 1
Access: (0775/-rwxrwxr-x)  Uid: ( 1000/   andre)   Gid: (  984/   users)
Access: 2025-08-16 18:22:29.563531700 -0700  <----
Modify: 2025-01-12 08:10:30.802080000 -0800  <----
Change: 2025-09-11 20:34:01.195135500 -0700  <----
 Birth: -

Here is the EXIF data.

> exiftool picrew-concept.jpg
ExifTool Version Number         : 13.30
File Name                       : picrew-concept.jpg
Directory                       : .
File Size                       : 65 kB
File Modification Date/Time     : 2025:01:12 08:10:30-08:00  <----
File Access Date/Time           : 2025:08:16 18:22:29-07:00  <----
File Inode Change Date/Time     : 2025:09:11 20:34:01-07:00  <----
File Permissions                : -rwxrwxr-x
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Big-endian (Motorola, MM)
Current IPTC Digest             : b61256b6eb9a69a9475e87fd9891ff40
Coded Character Set             : UTF8
Envelope Record Version         : 4
Keywords                        : oc, vivian, pokemon
Application Record Version      : 4
XMP Toolkit                     : Image::ExifTool 12.54
Subject                         : oc, vivian, pokemon
Hierarchical Subject            : oc, oc|vivian, pokemon
Profile CMM Type                : 
Profile Version                 : 4.3.0
Profile Class                   : Display Device Profile
Color Space Data                : RGB
Profile Connection Space        : XYZ
Profile Date Time               : 2016:01:01 00:00:00
Profile File Signature          : acsp
Primary Platform                : Unknown ()
CMM Flags                       : Not Embedded, Independent
Device Manufacturer             : 
Device Model                    : 
Device Attributes               : Reflective, Glossy, Positive, Color
Rendering Intent                : Media-Relative Colorimetric
Connection Space Illuminant     : 0.9642 1 0.82491
Profile Creator                 : 
Profile ID                      : 0
Profile Description             : sRGB
Red Matrix Column               : 0.43607 0.22249 0.01392
Green Matrix Column             : 0.38515 0.71687 0.09708
Blue Matrix Column              : 0.14307 0.06061 0.7141
Media White Point               : 0.9642 1 0.82491
Red Tone Reproduction Curve     : (Binary data 40 bytes, use -b option to extract)
Green Tone Reproduction Curve   : (Binary data 40 bytes, use -b option to extract)
Blue Tone Reproduction Curve    : (Binary data 40 bytes, use -b option to extract)
Profile Copyright               : Google Inc. 2016
Image Width                     : 1050
Image Height                    : 1132
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
Image Size                      : 1050x1132
Megapixels                      : 1.2

It looks like the file system data and the EXIF data match.

What is the specific type of data that I need to modify to match the system data? I can recursively update the fields if I know what OneFolder reads.

Thank you for looking into this!

[bibbleskit]

Clearer information:

> stat marthdew-dtiys.png | grep -i modi; exiftool marthdew-dtiys.png | grep -i modi
Modify: 2025-04-19 17:09:53.751779200 -0700
File Modification Date/Time     : 2025:04:19 17:09:53-07:00

OneFolder:

[Antoine-lb]

@bibbleskit we indeed have a problem, thanks for reporting!

Sadly, I am very low on development time for a couple of months, so it will take some time for me to resolve this problem, but I will fix it one day for sure !

In case you are low in patience, you can also try the other forks:

• Here is the original project: https://github.com/allusion-app/Allusion
• Here is a fork of the original project that is currently maintained. I recommend using this one: https://github.com/RafaUC/Allusion

Or if you want, you can always submit a PR, and I can review it

[bibbleskit]

@Antoine-lb I understand the lack of development time. Take all the time you need! Thank you for your work on this project, in general.

I'm back with more information. It looks like all the data is not actually being written as EXIF data. It appears to be XMP.

Here is a screenshot from within OneFolder:

This same image with the data extracted using python Pillow:

import PIL.Image
import PIL.ExifTags

image_path = "/path/to/picrew-concept.jpg"
img = PIL.Image.open(image_path)

exif = {
    PIL.ExifTags.TAGS[k]: v
    for k, v in img._getexif().items()
    if k in PIL.ExifTags.TAGS
}

print(exif)

Output:

projectfolder #:> python get_image_metadata.py
{'ResolutionUnit': 2, 'ImageDescription': 'test description', 'YCbCrPositioning': 1, 'XResolution': 72.0, 'YResolution': 72.0}

The image metadata in Gwenview (KDE image browser):

The tags are kept in the XMP fields "Hierarchical Subject" and "Subject" (and the IPTC "keywords").

And I'm not sure where OneFolder is getting the modify date, since it doesn't match up with any of the metadata.

projectfolder #:> stat picrew-concept.jpg  | grep -i modi; exiftool picrew-concept.jpg  | grep -i modi
Modify: 2025-01-12 08:10:30.000000000 -0800
File Modification Date/Time     : 2025:01:12 08:10:30-08:00

I don't know much about these meta data formats, so I don't want to speculate and say something that might not be helpful, haha. But I do hope that this is somewhat helpful in debugging. I would love to assist if I have the time because I loved Allusion, and OneFolder is absolutely a great step up in the right direction (truly portable via filemetadata is great.

---

Note, most of these files I am using are ported over from the original Allusion, so they did have metadata on them already. However, I have tried this with a completely new folder with new images untouched by the original Allusion. The issues were the same. I plan on doing more testing to see if it's something on my end.

[bibbleskit]

(I didn't mean to keep looking into this. ADHD is a bitch lol)

I cleared everything out of OneFolder, created a new directory in a completely unrelated path and copied some existing images into it.

Here are the stat and exiftool outputs for the dates.

Here is OneFolder:

It looks like the time I highlighted in pink matches the Birth time in stat's output.

If that's the case, then there isn't a way to correct the time in OneFolder by altering file metadata. As far as i know, Birth time is set by the filesystem for the inode of that file at creation and can't be altered.

Modified (highlighted green) appears to be based on the inode change time, instead of stat's "Modify" time, or exiftool's "File Modification Date/Time" attribute.