OS idea: Filesystem feature that understands .info files.

[ascendant]

Since .info files are basically metadata for actual data files, what if the file system was designed to recognize that? For example, if you copy a file, the file's .info file, if it exists, is automatically copied with it. Same with moves and deletes. The filesystem can just store the metadata alongside the file itself, they don't have to be separate files internally.

 I was wondering what people thought about that idea.

[AMIGASYSTEM]

Actually this already happens all the time on Amiga and AROS, OS4 and MOS, if you on Wanderer drag a file, it will be moved assimilated to the .info file.

In File Managers like Dopus4, you can decide to copy file and its Icon or copy only the file or only the icon.

On Amiga like AROS all files theoretically have an Icon, in fact to files that do not have an Icon, you can ask the system to create one, which you can also make real. Also, the system if it is well configured will assign an icon type based on the file type, on Amiga and AROS there are different types of Icons: Tool, Project, Folder, Disk and Trash

Amiga AROS Icons are very complex, no OS has this complexity, in its Tooltype you can add an infinity of parameters.
You can, for example, associate one type of images with different tools, so you can see more images with different tools.

[ascendant]

The design of the filesystem is such that it doesn't know or care about .info files right now. To it, these are just files like any other, as far as I understand.

The programs you describe specifically know how to deal with .info files. I am just proposing that the handling of .info files reside in the filesystem. That way, programs do not need to handle them, if that is not their design intent. This makes the programs simpler, pushing the complexity down into the OS.

Let's say you have a text editor. In that text editor's file dialog box, maybe it allows you to rename files. Right now, if the program is not written properly, it would rename the text file, but if there were a .info file associated with it, that would not be renamed also.

I see this in shell scripts. For example, the Scalos install script copies both the Scalos and Scalos.info files into the requested install directory.

[AMIGASYSTEM]

Many Text Editors, but also image editors, music editors etc.. in the options usually have the option to save the file with Icon, even when the file did not have an icon, consequently if you do save as, the new renamed file will have its icon renamed.

Also alche on Wander if you rename a file, its icon will also be renamed, on the Filemanagers you can choose to automatically rename/copy/move file or icon or just file, or just icon.

The convenience of the external icon (no other OS has this possibility) allows you to swap icons between files, you can for example on a file of any type swap icons, you can also do it between folder icon and project icon etc.., then from the tooltype change the type.

[AMIGASYSTEM]

On the Amiga AROS, file extensions are optional, files are usually not recognized by exension but by content, e.g. to a JPG image the system will assign a specific icon, this will not change even you change exension, e.g. if you rename a .jpg file to mp3, the system will always assign an icon depicting a jpg image.

See out this old comprehensive video of mine
https://www.youtube.com/watch?v=d7RaIa91QaU

[OlafS3]

The design of the filesystem is such that it doesn't know or care about .info files right now. To it, these are just files like any other, as far as I understand.

The programs you describe specifically know how to deal with .info files. I am just proposing that the handling of .info files reside in the filesystem. That way, programs do not need to handle them, if that is not their design intent. This makes the programs simpler, pushing the complexity down into the OS.

Let's say you have a text editor. In that text editor's file dialog box, maybe it allows you to rename files. Right now, if the program is not written properly, it would rename the text file, but if there were a .info file associated with it, that would not be renamed also.

I see this in shell scripts. For example, the Scalos install script copies both the Scalos and Scalos.info files into the requested install directory.

That is handled by the desktop. On AROS you have 3 desktops with Wanderer, Scalos and Magellan. Depending on the desktop that is already possible.

[miker1264]

In addition AROS and Amiga use def icons for files or directories with no icons. If they don't have an icon a default icon is generated according to file type (file descriptor).

So if you have a Jpeg file and you rename it or move it the jpeg file still has the same icon but with a new name or new location. So in a sense the system handles def icons by itself. A dedicated icon isn't needed. But if the icon is available it will be used or a default icon will be assigned.

Replacing all AROS icons with def icons isn't desired because icons perform other tasks other than just looking good. They can contain Tooltypes, Default Tool, etc.

[ascendant]

Sorry, I don't think I explained it very well. The system behavior wouldn't change for the end user. But anyway, it was just an idea.

[o1i]

If the filesystem moves the .info files together with the data file a lot of the old software would not work anymore. The scalos install script would copy the executeable (and the filesystem the icon), then the script would copy the .info file (again). The script might fail as there is already an icon. Assume a program that moves a jpg plus icon to a new directory. It would fail on the icon as the filesystem already moved the icon and it could not find an icon file to move anymore.

[cdimauro]

Since .info files are basically metadata for actual data files, what if the file system was designed to recognize that? For example, if you copy a file, the file's .info file, if it exists, is automatically copied with it. Same with moves and deletes. The filesystem can just store the metadata alongside the file itself, they don't have to be separate files internally.

 I was wondering what people thought about that idea.

That's a very bad idea. A filesystem should NOT have this responsibility: an icon file is and should remain just a file like any other.

It's the desktop manager (or any other application which is handling files/folders on devices) which has and should have the responsibility for correctly handling the icon file which is associated to a specific file or folder.

BTW, having separate files for icons is another Bad Design choice which Commodore's (Amiga) engineers made.
In fact, an icon should be part of the metadata associated to a specific file (exactly like files' comment are!) and NOT a separate entity found on the filesystem.

[ascendant]

Since .info files are basically metadata for actual data files, what if the file system was designed to recognize that? For example, if you copy a file, the file's .info file, if it exists, is automatically copied with it. Same with moves and deletes. The filesystem can just store the metadata alongside the file itself, they don't have to be separate files internally.

 I was wondering what people thought about that idea.

That's a very bad idea. A filesystem should NOT have this responsibility: an icon file is and should remain just a file like any other.

It's the desktop manager (or any other application which is handling files/folders on devices) which has and should have the responsibility for correctly handling the icon file which is associated to a specific file or folder.

BTW, having separate files for icons is another Bad Design choice which Commodore's (Amiga) engineers made.
In fact, an icon should be part of the metadata associated to a specific file (exactly like files' comment are!) and NOT a separate entity found on the filesystem.

I am confused by this. I agree that there should not be separate files for icons, and that they should be part of a file's metadata. How would this be implemented if not done by the filesystem?

[AMIGASYSTEM]

ascending, as said the Amiga Icons is like real applications, on AMiga AROS the icons are not generic, the same icon cannot be used on different hardware, system or configurations, in the icon you set the Tooltypes according to the needs of the user, harware and program.


On the Amiga you can run an application directly through a "Tool" icon, but it can also run as a "project" icon if it is included in a script, this is decided by the user and not the system, based on their configuration, the type of OS or the hardware used.

[cdimauro]

Since .info files are basically metadata for actual data files, what if the file system was designed to recognize that? For example, if you copy a file, the file's .info file, if it exists, is automatically copied with it. Same with moves and deletes. The filesystem can just store the metadata alongside the file itself, they don't have to be separate files internally.

 I was wondering what people thought about that idea.

That's a very bad idea. A filesystem should NOT have this responsibility: an icon file is and should remain just a file like any other.

It's the desktop manager (or any other application which is handling files/folders on devices) which has and should have the responsibility for correctly handling the icon file which is associated to a specific file or folder.

BTW, having separate files for icons is another Bad Design choice which Commodore's (Amiga) engineers made.
In fact, an icon should be part of the metadata associated to a specific file (exactly like files' comment are!) and NOT a separate entity found on the filesystem.

I am confused by this. I agree that there should not be separate files for icons, and that they should be part of a file's metadata. How would this be implemented if not done by the filesystem?

The filesystem should implement a generic metadata storage for each file. Then it's up to the desktop manager / application to use proper filesystem APIs to create / change / delete specific metadata containing the icon (or a comment, or... other).

[ascendant]

The filesystem should implement a generic metadata storage for each file. Then it's up to the desktop manager / application to use proper filesystem APIs to create / change / delete specific metadata containing the icon (or a comment, or... other).

What I proposed was basically a stepping stone to this. I thought, since the icon file is so pervasive, it should continue to be visible. But this proposal basically eliminates it entirely. I think it could still be doable while supporting software which does not understand that the icon file doesn't exist as a separate file.

So you have a generic metadata-capable filesystem, but the library with which software interfaces into that filesystem has the "classic" APIs, and the newer APIs. Legacy software using the classic APIs will continue to "see" .info files. For example, when listing out the contents of a drawer, the library would read each file's metadata to see if it contains icon info, and then list out a fake .info file.  The updated API would not list that out at all. The software would need to request the metadata specifically.

[AMIGASYSTEM]

I think you should try an Amiga/AROS system, the Amiga/AROS icons, to understand how the icons work, which are completely different from the PC/Linux icons, although to separate files, in a sense they are joined.

 I'll give you an example, if on Amiga/AROS you make a shortcut of the file on the "desktop", its icon will be moved to the desktop, if you delete it, automatically you will also delete the file, so automatically you will delete both the file and its icon