Hacker News Reader

Comment by willvarfar | Hacker News Reader

The idea of storing the icon in the inode is interesting.

Conventionally, when displaying a folder, a file manager identifies the _type_ of each file, and then looks up the appropriate icon.

Does Haiku instead display whatever icon is in the inode? Could a wordprocessor document masquarade as a spreadsheet, and such?

I can't think of any security implications of this, nor think of any real mischief that a developer might cause, but I also can't think of any big advantage of it either. What use-case for having the whole icon in the inode instead of just a mime-type that is then used to look up the (already parsed, and shared) icon?

View on HN

Even Windows has resources, including icons, inside the exe file. Obviously a bit different (it's not in metadata, it's in the actual executable) but the idea that a single file named PerfectlyHarmlessPhoto.jpg.exe could have an icon of a jpeg file turns your computer in a botnet client is not a novel one.

Afaik in contemporary Mac OS, you have a directory with certain files in it. I'm not sure if anything prevents you from naming the directory PerfectlyHarmlessPhoto.jpg.app and giving it a jpeg icon. You would need to get the user to extract an archive first, which may be more or less difficult.

I think the Linux practice of having a separately identified file provide the icon is relatively rare. (I just checked Nautilus and ROX-Filer, and ROX-Filer shows .desktop icon files and allows you to execute them directly. Nautilus treats them like any other configuration file. I guess it would be relatively difficult to trick a Nautilus user into executing a script they thought was an image.)

The article claims that reading from the disk is extremely slow and so this results in a significant speed up. It is pretty quick to parse the images compared to reading the files off disk.

If the security considerations are relevant, you could presumably write the operating system not to render the icon of non-installed software tools.

> I think the Linux practice of having a separately identified file provide the icon is relatively rare

Windows File Manager primarily uses the extension, e.g. all DOC files are shown with the MS Word logo.

More recently, they have generated thumbnails for a lot of media files too.

I was referring specifically to the limited case of executables. As I mentioned, executables in Windows have a resource that is the icon. There's probably no real security issues in having a photo show up with a Word document icon.

Windows File Manager (which was used till Windows 3.11 and Windows NT 3.51) doesn't show generated thumbnails, although Windows Explorer does.

I actually think HVIF is one of the few things Haiku has done that's good engineering and deserves to see more use in something actually popular but it's very niche.

Per-file icons is a nice way to get cheap previews, especially at higher resolutions. For 2D images a fairly naive previewing method is to just flatten the whole image and scale it. For a PDF it will often but not always be useful to render the first non-empty page, then as you get into video, 3D or sounds it all starts to trickier.

However of course HVIF doesn't benefit any of these use cases, it's at its best when an artist has spent some effort learning techniques specific to the format and then hand crafts each icon accordingly.

HVIF in practice mostly gives icons to application software, so this technique lets Haiku use the directory of binaries to get back a set of icons for the applications those binaries implement, without doing a small file read per application as would happen in say Windows. A small advantage.

> The idea of storing the icon in the inode is interesting.

The Amiga did something similar except with a sidecar file (.info)

http://krashan.ppa.pl/articles/amigaicons/

> What use-case for having the whole icon in the inode

One that springs to mind is that you could put a thumbnail of the document into the icon (although I guess that's a bit tricky with only 500 byte SVG-alike icons.)

The use case is to get file specific icons, rather than just type specific. One thing is thumbnails, but a lot of applications and games on the Amiga for example have custom icons.

Of course that doesn't require it to be in the inode (it isn't for the Amiga - it's in <filename>.info).

On the Amiga the ".info" file can also contain additional information, such as startup instructions, as well as snapshotted location in the UI - the Amiga Workbench was close to a reasonably spatial file manager (and I really miss that..).

Security implications certainly would be different than they were at the time, in that you could trick people to start executables instead of loading the file into an application they trust, but that really is best handled by warning people on execution of "new"/downloaded files anyway.

Amiga icons really felt like they were miles ahead of the competition and I'm surprised more of their possibilities didn't take off in other OSes.

- could change the icon for individual files/folders

- could have differently-sized icons

- different icons for unclicked + clicked state

You could do this on classic MacOS - you could copy an image and paste it into the icon box in a files' properties. So yes, you could disguise your video games / hacking tools / illicit images as perfectly respectable ClarisWorks documents.

Still can do this.

Mainly just a fun prank to change the icons without breaking stuff.

The performance use case is most significant to me. But I’m not sure why the OS wouldn’t look up all the icons used in a folder and only read them once for reuse. So having a thousand Word documents would only need one read of the Word icon.

I think it’s a nice packaging feature to not need to distribute a separate icon file, rather just include the icon in the file directly.

Reply on news.ycombinator.com