AROS World Exec
General => General Chat => Topic started by: ascendant on May 10, 2023, 04:18:16 PM
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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).
-
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.
-
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
-
Small example of what you can add in the Tooltyps icon, this icons for example cannot be generic, no Amiga/AROS icon can be generic
(https://ae.amigalife.org/index.php?action=dlattach;topic=1125.0;attach=4925;image)
-
@ascendant
I gave some though to this idea and I see a couple of problems you would have to solve. They all originate with convention that: "A file can be accompanied by .info file. If that's the case, both files need to be managed together". As said this is convention that has been there from late 80s, not something guaranteed by any API. All software created so far was written understanding that such convention exists.
The first problem I see is something @o1i already mentioned. A program will try to operate on .info file after it operated on regular file. If the filesystem operates on the .info file first, then program might survive this or might crash. All depends on how it was written. Majority of software created for 68K won't have sources that can be adjusted as well as some AROS programs comes in binary-only/close source form.
Another problem to overcome would be more of a question "which filesystem"? If you modify just one of them, say SFS for example, then FAT and NTFS would still have the old behavior. Thus and application would actually need to understand which file system it is running and have two code path - one for "new", one for "old" systems. This would however mean your goal of simplifying applications could not be achieved. Possibly a more general place to do this would actually be the dos.library and I think you already hinted on this with your comment above about classic API and new API.
Finally, there comes a challenge of cross-platform development. With the community of developers with have around AmigaOS, MorphOS and AROS is relatively small there is great value for each of the systems if a developer creates application that can be compiled for all three of them. To do that however, the developer expect same API and same behavior across all platforms. If AROS exposes the new API then the 3rd party developer will either not use it, because that's additional work for him or he will end up with two code paths in his application, which does not make the application simpler.
-
Thanks for your thoughts on this. As for problems one and two, I think they could be solved with smarts embedded in the dos.library. But keeping API compatibility with classic Amiga makes it a non-starter.
-
@deadwood: ntfs has something like that. You can have a file associated with a directory and those two will always stay together. Try saving a web page with IE, it saves a .html file and a dir which are glued together (afair)
-
Yes this happens with all Browse, in fact if you download a web page, if you then delete the file, the folder will also be deleted
-
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.
Keeping backward compatibility with the existing applications is hard, as deadwood already reported. But it's doable.
Specifically, you need two things:
- a filesystem which supports metadata per each file or folder;
- the filesystem implementation which should report a .info file for each existing file or folder (if no .info real file exist for them).
So, the idea is to have a sort of "virtual icon" which is always generated for files or folders which have no .icon file. When an application tries to access it, then the filesystem implementation transparently intercepts it and proceed as follows:
- it checks if there is a specific metadata associated to the file / folder. If yes, it extracts it and gives back the content, as per the application requests;
- if no metadata is found, then it checks (using proper o.s. APIs) if there's a default icon which is usable, and gives it back its content;
- if no metadata and no default icon are found, then it gives back an empty file.
If there's a real .info file present on the device (which is the normal Amiga o.s. scenario) then the filesystem implementation does nothing (it works as usual).
This solution is 100% backward-compatible with all Amiga o.s. applications.
However it has a drawback: the modern filesystem always reports a .info file for each file or folder in the device, even if there's absolutely nothing (I mean: no real .info file neither icon metadata or default icon). Which might be an acceptable solution, anyway.
BTW, you don't need to always check the metadata content: you need to access it only when the icon data is needed (e.g.: its content should be given back to the requesting application).
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
I think that you should try to understand what people are talking about before replying.
@ascendant
I gave some though to this idea and I see a couple of problems you would have to solve. They all originate with convention that: "A file can be accompanied by .info file. If that's the case, both files need to be managed together". As said this is convention that has been there from late 80s, not something guaranteed by any API. All software created so far was written understanding that such convention exists.
The first problem I see is something @o1i already mentioned. A program will try to operate on .info file after it operated on regular file. If the filesystem operates on the .info file first, then program might survive this or might crash. All depends on how it was written. Majority of software created for 68K won't have sources that can be adjusted as well as some AROS programs comes in binary-only/close source form.
See above for a possible solution.
Another problem to overcome would be more of a question "which filesystem"? If you modify just one of them, say SFS for example, then FAT and NTFS would still have the old behavior. Thus and application would actually need to understand which file system it is running and have two code path - one for "new", one for "old" systems. This would however mean your goal of simplifying applications could not be achieved. Possibly a more general place to do this would actually be the dos.library and I think you already hinted on this with your comment above about classic API and new API.
MacOS creates hidden files to store its metadata (because it has some) on "alien" (non HFS or AFS) filesystems, like FAT32. Something like that could be made for/on AROS or other Amiga-/like o.ses.
NTFS already supports metadata since ages, so embedding icons (or other things) is already possible.
The "only" thing which is needed is having proper FAT32, NTFS, etc. AROS / Amiga o.s implementations which take care of the new icons model, as per my above explanation.
Finally, there comes a challenge of cross-platform development. With the community of developers with have around AmigaOS, MorphOS and AROS is relatively small there is great value for each of the systems if a developer creates application that can be compiled for all three of them. To do that however, the developer expect same API and same behavior across all platforms. If AROS exposes the new API then the 3rd party developer will either not use it, because that's additional work for him or he will end up with two code paths in his application, which does not make the application simpler.
See above: not needed. However AROS developers need to implement the new stuff...
@deadwood: ntfs has something like that. You can have a file associated with a directory and those two will always stay together. Try saving a web page with IE, it saves a .html file and a dir which are glued together (afair)
That's a different thing which doesn't use NTFS's metadata: it's all about the browsers and how they work.
However NTFS is a modern and very advanced filesystem which can be used for the above (and also to natively implement Amiga's comments attached to files / folders).