disk.info (ram disk) - directory?!?

[thomas]

I once made a program which makes a real disk.info in RAM and maintains a copy of it on harddisk: http://aminet.net/util/misc/snapvol.lha

With this you don't have an object which is listed as a dicrectory and it also works on RAM disks below 3.9.

[AMIGASYSTEM]

Thomas Thank you, your application works perfectly on my AFA OS (see video attached)

The link you have attached does not work, this of your site works instead: http://thomas-rapp.homepage.t-online...ds/snapvol.lha

[thomas]

The link does work. But indeed it is not the one I intended to post. I hate it if people post direct download links. This is the link to the description: http://aminet.net/package/util/misc/snapvol

[honx]

giving snapvol a try as all other suggestions were a bit too complicated for me.
replaced makelink line in startup-sequence with snapvol (#1) looks much better (#2)!

readme states that on os3.9 systems >bb2 it would be better using makelink instead.
but this "solution" produced that bug/error, so snapvol is also best choice for >bb2!

[AMIGASYSTEM]

Originally Posted by thomas

I hate it if people post direct download links.

I'm sorry, i post direct download links for problems aesthetics to improve the reading of the post

[James]

Originally Posted by mark_k

Soft links are a bit weird in AmigaDOS. Some programs which weren't designed to handle them think they are directories. I guess that includes Cir!

Exactly, this proves there is a problem with dir and list, not makelink. When I first got a graphics card OS3.1 screenmode prefs totally messed up the number of colours reported. Based on the logic in this thread I would have binned the graphics card.
We should be looking to replace the inadequate software instead.
Newdir has no problem recognising the softlink:



I've been using the makelink method for almost 20 years, and would require evidence of much more serious problems than this to convince me to stop using it.

[honx]

how do i get such a colourful shell like shown in your attachment?

[James]

Originally Posted by honx

how do i get such a colourful shell like shown in your attachment?

It doesn't look that colourful most of the time, my default look is white text on a black background. Some commands use their own colour hi-lighting. The fact that the text has stayed red after the newdir command was run proves that newdir also has it's problems.

The list command that comes with PFS doesn't report softlinks, but doesn't misreport them as directories either:



Here is my VNC prefs:

VNCPrefs.lha

S:Shell-Startup can also affect how your shell looks.

[PeterK]

Originally Posted by James

Exactly, this proves there is a problem with dir and list, not makelink. ... Newdir has no problem recognising the softlink:

Sorry, I have to apologize for suspecting MakeLink to be the culprit. But after looking into the autodocs of dos.library of OS 2.04 I just wonder why CBM did never update the dir and list instructions ??

dos.library/MakeLink
    NAME
 MakeLink -- Creates a filesystem link (V36)
    SYNOPSIS
 success = MakeLink( name, dest, soft )
 D0       D1    D2    D3
  BOOL MakeLink( STRPTR, LONG, LONG )
    FUNCTION
 Create a filesystem link from 'name' to dest.  For "soft-links",
 dest is a pointer to a null-terminated path string.  For "hard-
 links", dest is a lock (BPTR).  'soft' is FALSE for hard-links,
 non-zero otherwise.
  Soft-links are resolved at access time by a combination of the
 filesystem (by returning ERROR_IS_SOFT_LINK to dos), and by
 Dos (using ReadLink() to resolve any links that are hit).
...
   BUGS
 In V36, soft-links didn't work in the ROM filesystem.  This was
 fixed for V37.

Hmm ... OS 3.1 Dos.h:

/* Values for MakeLink() */
#define LINK_HARD 0
#define LINK_SOFT 1 /* softlinks are not fully supported yet */

dosextens.h:

/* Types for fib_DirEntryType. NOTE that both USERDIR and ROOT are */
/* directories, and that directory/file checks should use <0 and >=0. */
/* This is not necessarily exhaustive! Some handlers may use other */
/* values as needed, though <0 and >=0 should remain as supported as */
/* possible. */
#define ST_ROOT 1
#define ST_USERDIR 2
#define ST_SOFTLINK 3 /* looks like dir, but may point to a file! */
#define ST_LINKDIR 4 /* hard link to dir */
#define ST_FILE -3 /* must be negative for FIB! */
#define ST_LINKFILE -4 /* hard link to file */
#define ST_PIPEFILE -5 /* for pipes that support ExamineFH */

support.asm OS 3.1:

_MakeLink:
	move.l	#ACTION_MAKE_LINK,d0	; works by luck - common saves d2/d3!!
	bra.s	obj_common

[daxb]

Filesystems also need to support links. SFS docs say it doesn't support hardlinks, only softlinks. PFS comes with his own Makelink command because it says the WB Makelink has problems with softlinks. It seems it all depends on (luck).

[AMIGASYSTEM]

Originally Posted by James

Attachment 56249

James what utility did you use to get the 2 tags (Help and Setting) on the window AmigaShell, thank you !

[PeterK]

Originally Posted by thomas

What happens if the user drags the icon somewhere or resizes the window and tries to snapshot it? Does your library save the changes to the def icon?

Just thought about your question again, and I couldn't find a good reason why my icon.library should stay compatible to v45.1 in case of Ram Disk or trashcan icons. Both exist only once on Workbench (unlike disk, drawer, project or tool), so why deleting their position and not writing the window settings back to their def icons in ENVARC:Sys ? I will try that soon ...

[James]

Originally Posted by daxb

Filesystems also need to support links. SFS docs say it doesn't support hardlinks, only softlinks.

Well this is a softlink, so good enough...

Originally Posted by daxb

PFS comes with his own Makelink command because it says the WB Makelink has problems with softlinks.

I owned PFS before OS3.9 was released, so was aware of this claim when I updated to OS3.9, but decided to try using the OS version many years ago.
Still not seen any real problems in this one use case (have not used makelink for anything else).

Originally Posted by AMIGASYSTEM

James what utility did you use to get the 2 tags (Help and Setting) on the window AmigaShell, thank you !

That is a feature of VNC, it will not appear if SHELL is not set in tooltypes:

Originally Posted by PeterK

Just thought about your question again, and I couldn't find a good reason why my icon.library should stay compatible to v45.1 in case of Ram Disk or trashcan icons. Both exist only once on Workbench (unlike disk, drawer, project or tool), so why deleting their position and not writing the window settings back to their def icons in ENVARC:Sys ? I will try that soon ...

What about changing the icon image?

[PeterK]

Originally Posted by James

Well this is a softlink, so good enough...

But not good enough for amber-ram-handler...

What about changing the icon image?

Writing a fake icon to RAM:disk.info should be redirected completely, including the images, to ENVARC:Sys/def_RAM.info instead of creating a real icon for RAM: And ghosting could also be disabled. The same exception for the trashcan. Is that a good idea?

[AMIGASYSTEM]

Originally Posted by James

That is a feature of VNC, it will not appear if SHELL is not set in tooltypes:

Thank you

[PeterK]

Originally Posted by PeterK

Writing a fake icon to RAM:disk.info should be redirected completely, including the images, to ENVARC:Sys/def_RAM.info instead of creating a real icon for RAM: And ghosting could also be disabled.

Ok, done. But it works on OS 3.5/3.9 only. And I didn't make any changes for the trashcan. Never use it and not sure if there are any problems with the trashcan, too?

[mark_k]

There is more than one trashcan icon (one on each drive/partition) so it wouldn't be appropriate to link all drives' trashcan icons to the same file.

[PeterK]

Yes, that's one reason why I didn't change anything for trashcans. And usually they have real icons anyway.

[AMIGASYSTEM]

Furthermore Peter "GlobalTrash" use two Icons "def_Trashcan.info and def_TrashcanFull.info"

[ Show youtube player ]