Opened 3 years ago
Closed 3 years ago
#17619 closed bug (fixed)
Problems with Tracker image thumbnails and FAT32 disks
Reported by: | danboid | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta4 |
Component: | Applications/Tracker | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I read in the recent Haiku update that Trackers thumbnail support was supposed to be fixed but it only seems to fully work for images stored on BeFS disks. If I open a folder of jpeg images stored on a FAT32 disk under 55908 Tracker only generates a thumbnail for one image or sometimes a few per folder but never all of the images. This occurs whether I mount the disk RW or RO.
Change History (13)
follow-up: 8 comment:1 by , 3 years ago
Keywords: | tracker image thumbnails fat32 removed |
---|
comment:2 by , 3 years ago
Tracker should do it like both caja and Thunar do under Linux for non BeFS filesystems and create thumbnails in a hidden folder within the users home dir or some other cache location else on the system disk.
You say this feature is BeFS only but it does actually work a bit already for files stored on FAT32 but only for a few files so that is a bit of an odd bug.
comment:3 by , 3 years ago
The point of using extended attributes is that there is no way this can possibly desync, using some hidden folder is more of a hack if you don't have these capabilities at all.
I agree that tracker showing /some/ thumbnails only is more of a bug, it should show all or none. But this does not answer the question of how these should be stored if they cannot be stored in the normal way. (This is also problematic for other reasons, i've recently discovered the open tool breaks on Fat32 too, for example to install hpkg from a thumb drive that is fat32)
You say this feature is BeFS only
No, I said that fat32 does not support this, you need a filesystem with extended attributes and there are more filesystems that support it, like ext4, ZFS, btrfs, xfs etc (I think we have support for ext and xfs a bit, not too sure)
comment:5 by , 3 years ago
File systems are irrelevant here, if there is a feature to show thumbnails, it should work on all file systems, regardless of whether the file system supports it or not.
Hidden folders are used for all sorts of things regarding view properties in other operating systems, so it shows that they definitely can be used.
comment:6 by , 3 years ago
Problem can be solved on file system level so attributes will be available on any file system. If it are not available natively, emulation with hidden directory will be used.
comment:7 by , 3 years ago
That neither solves the problem of a RO mount nor of system packages. extended attributes are not always available.
File systems are irrelevant here, if there is a feature to show thumbnails, it should work on all file systems, regardless of whether the file system supports it or not.
What is this comment supposed to accomplish? I gave a technical explanation of why this feature does not work as expected. If you don't have anything to add to the ticket please do not comment, as per the etiquite: https://dev.haiku-os.org/wiki/BugTrackerEtiquette
comment:8 by , 3 years ago
Replying to nephele:
I don't know if there is any good solution here, perhaps using some other filesystem for your portable storage would work better?
File systems are irrelevant, because it is up to the user's choice. User can select the best file system that suits their needs, and still expect the thumbnails to work. That's why it needs to be independent of file system selection, whether it supports extended attributes or not. RO folders can be fixed in another way, it's not a big issue.
Replying to nephele:
What is this comment supposed to accomplish? I gave a technical explanation of why this feature does not work as expected. If you don't have anything to add to the ticket please do not comment, as per the etiquite: https://dev.haiku-os.org/wiki/BugTrackerEtiquette
Please see my explanation above, I added my point. I also feel that you are framing and attacking me personally, so I will point out that as a moderator-status person here, it is extremely uncool of you. Please refrain from doing so, you can contact me personally if you have any personal remarks. I will not comment further.
comment:9 by , 3 years ago
It is surprising that Tracker would generate thumbnails for even one image on FAT32.
If the file system doesn't support attributes it shouldn't generate thumbnails at this point. Well, that's not completely true, it will generate thumbnails on unsupported file systems if the BEOS:TYPE attribute is present, but that should only happen if the file is on BFS. If we extend Tracker's type detection at some point (we already have a system to identify types,) we'll be able to get thumbs on other file systems working eventually.
comment:10 by , 3 years ago
it will generate thumbnails on unsupported file systems if the BEOS:TYPE attribute is present
FAT uses an attributes emulation layer that guesses mimetypes based on file extensions. So, it makes sense we would see some thumbnails even on FAT.
comment:12 by , 3 years ago
Hi waddlesplash
Yes, using the latest nightly I can now view the thumbnails for a bunch of jpgs stored on a FAT32 disk. Excellent work!
Sorry for the delay in testing this but I've not had a machine to test Haiku on for a couple of months.
comment:13 by , 3 years ago
Milestone: | Unscheduled → R1/beta4 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Thanks for testing!
This happens because the image thumbnails are generated and then stored inside extended attributes of the files. Fat32 has no support for extended attributes in the filesystem, there is not much we can do about this. You might also see that image thumbnails do not work for the same reason if you are inside a RO directory of a package.
The question is a bit whether it makes sense to have something like an overlay filesystem to store those, generate them in tracker only or perhaps do that ahead of time.
The downside for the ahead of time aroach would be that you would have to scan the entire usb drive for files on each mount, it seems a bit overkill. the aproach of thumbnailing on demand would also have to open all files in a directory each time you visit it the first time after a mount.
I don't know if there is any good solution here, perhaps using some other filesystem for your portable storage would work better?