Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#9761 closed bug (duplicate)

Tracker doesn't update image files

Reported by: Giova84 Owned by: axeld
Priority: normal Milestone: R1
Component: File Systems/BFS Version: R1/Development
Keywords: Cc:
Blocked By: #3150 Blocking:
Has a Patch: no Platform: x86

Description

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".

Change History (15)

comment:1 by anevilyak, 7 years ago

Component: Applications/TrackerApplications/Screenshot
Owner: changed from axeld to nobody

That sounds more like a problem in the screenshot app.

comment:2 by Giova84, 7 years ago

Nope. This also occurs with WonderBrush.

comment:3 by Giova84, 7 years ago

Component: Applications/ScreenshotFile Systems/BFS
Owner: changed from nobody to axeld

comment:4 by anevilyak, 7 years ago

Component: File Systems/BFS- General
Owner: changed from axeld to nobody

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.

comment:5 by Giova84, 7 years ago

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.

comment:6 by anevilyak, 7 years ago

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.

comment:7 by Giova84, 7 years ago

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

comment:8 by anevilyak, 7 years ago

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

comment:9 by Giova84, 7 years ago

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)

comment:10 by anevilyak, 7 years ago

Component: - GeneralFile Systems/BFS
Keywords: Tracker doesn't update image files removed
Owner: changed from nobody to axeld

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.

comment:11 by Giova84, 7 years ago

Ok. In anyway, this issue is back.

comment:12 by Giova84, 7 years ago

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"!

comment:13 by anevilyak, 7 years ago

Blocked By: 3150 added
Resolution: duplicate
Status: newclosed

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.

comment:14 by Giova84, 7 years ago

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.

comment:15 by anevilyak, 7 years ago

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.

Note: See TracTickets for help on using tickets.