Tracker doesn't update image files

[Giova84]

I have noticed that Tracker doesn't update image files. Eg: I take a screenshot named "screenshot1.png", and this screenhot contain a picture of WebPositive. Then i take another screenshot, this time of the Desktop. I will save this screenshot, again, as screenshot1.png, overwriting the previous one. Now i open this last screenshot: it show again WebPositive (like the first screenshot), but if i rename screenshot1 to screenshot2 the image will be updated.

hrev45606 and i have also noticed that since months.

Maybe is related to Be File Sytem? For now i set "Tracker".

[anevilyak]

That sounds more like a problem in the screenshot app.

[Giova84]

Nope. This also occurs with WonderBrush.

[anevilyak]

Then you're going to have to provide a better description of the problem, as it's not reproducible here, at least not with your current description. If I e.g. take a screenshot, save it, then take a second screenshot and save it with the same name (what it sounds like you're saying to do), it gets overwritten exactly as it should. Also, please stop wild guessing the component.

[Giova84]

The issue which i described, is exactly as is described. If i save an image (i have used the example of screenshot) and then i overwrite this image with a new content, is displayed the previous image. If i rename the file, the content of image will be updated. Since this doesn't occurs on NTFS (always inside Haiku) i was thinking to Be File System. The mine ain't a wild or random guessing.

[anevilyak]

Sounds entirely likely that you have a corrupt BFS partition then. As stated, this problem doesn't occur over here, with any app. Quite likely this is ultimately a duplicate of #3150.

[Giova84]

checkbfs doesn't report any issue and i don't notice any other issue about file system.

[anevilyak]

Please attach a syslog from the time frame when you were saving these files.

[Giova84]

I have rebooted Haiku and i'm no longer able to reproduce this issue. Can you leave this ticket open? If i will encounter again this issue i will investigate deeper. In anyway this is the last part of syslog after files operation:

KERN: bfs: bfs_open_dir:1615: Not a directory
KERN: libnetwork.so running in R5 compatibility mode.
Last message repeated 1 time
KERN: bfs: bfs_open_dir:1615: Not a directory
KERN: bfs: InitCheck:314: Bad data
KERN: bfs: KERN: inode at 1596999 is already deleted!
KERN: bfs: InitCheck:314: Bad data
KERN: bfs: inode at 1596999 is already deleted!

Output of checkbfs:

Ϟ 01:20:05 Ϟ ~ checkfs /boot
        69650 nodes checked,
        0 blocks not allocated,
        0 blocks already set,
        0 blocks could be freed

        files           62112
        directories     5565
        attributes      1160
        attr. dirs      782
        indices         31

        direct block runs               67283 (4.71 GiB)
        indirect block runs             337 (in 12 array blocks, 91.20 MiB)
        double indirect block runs      0 (in 0 array blocks, 0 bytes)

[anevilyak]

While I'll let Axel confirm/refute, I believe those syslog messages about the inode already being deleted do in fact indicate an FS structural problem. Also note that checkfs can't find/fix every possible problem, so the fact that it comes up clean doesn't necessarily mean you're in the clear in that respect.

[Giova84]

Ok. In anyway, this issue is back.

[Giova84]

A similar issue happens when i delete other kinds of files (eg text files)

KERN: bfs: Remove:2123: No such file or directory
KERN: bfs: Could not find value in index "size"!
KERN: bfs: Remove:2123: No such file or directory
KERN: bfs: Could not find value in index "last_modified"!

[anevilyak]

That's pretty much further confirmation of filesystem corruption. Closing as duplicate of #3150. My advice would be to copy as much of your data as you can to another volume/partition and reinitialize that one.

[Giova84]

I will. I also have a question. I initialize the disk, at least every 2/3 months, but this is not the first time that i noticed this filesystem issue. Why it happen? BeFS has some limit/bug? (on this disk i don't do anything of particular: just ordinary files operation). Thank you.

[anevilyak]

See #3150. If we knew why it happened, it would be fixed. Currently we don't, and none of the people who know those parts of the code have been able to reproduce the problem in order to analyze it.