RAM Disk: Where are the files here stored?

Foebane · 22 June 2018, 14:09

I've decided to use the RAM Disk for extracting archives to run the files from within them, and there is a Disk.info for the RAM Disk icon on Workbench, but at some point I extracted an archive that replaced the Disk.info with its own, and ruined the look of the Workbench.

So what I'm asking is, where in the System HDD can I find the files that appear within the RAM Disk: device, to make backups?

Predseda · 22 June 2018, 14:10

DH0:Prefs/ENV-archive I think? Not sure just now, but you can read it in DH0:s/startup-sequence.

Foebane · 22 June 2018, 14:25

Quote:

Originally Posted by Predseda

DH0:Prefs/ENV-archive I think? Not sure just now, but you can read it in DH0:s/startup-sequence.

Is there no folder in the DH0: root directory that contains them?

Predseda · 22 June 2018, 14:28

yes there is, and the folder is prefs/env-archive I believe

meynaf · 22 June 2018, 14:36

Files in ram: are copied from envarc: (usually prefs/env-archive) at startup.
So you can alter what you have in ram disk without any care - next reboot and everything will be like before.
And you can just backup your hdd, no need to do anything special for ram:.

Foebane · 22 June 2018, 18:39

Are you saying that if the files in RAM: are overwritten and THEN deleted, they will be restored to normal upon reset from the ENVARC: backups?

I tried deleting everything from RAM: and whilst the Disk.info and the single file in T were deleted, the folders were in use. Still, upon resetting, those files were restored.

I'm just wondering why the RAM: icon stayed changed after the overwrite and upon reset - maybe because I hadn't deleted it?

I can't see any files in ENVARC: relating to the RAM Disk - should I just remain assured that they're there and to count my blessings and leave it alone?

meynaf · 22 June 2018, 19:02

Errh... do you know what RAM is ?
Upon power up it is empty. So ENVARC: contents get copied to it. There is nothing to overwrite nor to delete.
If your ram disk icon has changed permanently, then the file that got overwritten wasn't in RAM. It was somewhere in your HD. If it's copying some disk.info to ram: that changed it then some program monitors that change and saves that file somewhere.
Default disk icon is normally env/sys/def_disk.info. Perhaps having a look there could tell more.

Foebane · 22 June 2018, 19:20

Quote:

Originally Posted by meynaf

Errh... do you know what RAM is ?
Upon power up it is empty. So ENVARC: contents get copied to it. There is nothing to overwrite nor to delete.
If your ram disk icon has changed permanently, then the file that got overwritten wasn't in RAM. It was somewhere in your HD. If it's copying some disk.info to ram: that changed it then some program monitors that change and saves that file somewhere.
Default disk icon is normally env/sys/def_disk.info. Perhaps having a look there could tell more.

Well, I'm on Bloodwych's ClassicWB Lite and I've been using Dopus to extract lha/lzx/zip archives from a Windows folder on the left to the RAM Disk on the right ("Arc Ext"). At some point, I was asked if I wanted to overwrite the Disk.info in the target folder (RAM) and that was when the permanent change occurred. I don't think it would've affected any DH0: (System) files.

I think my safest bet is to just not overwrite "Disk.info" or "file_id.diz" or anything like that. I'll see how I get on.

meynaf · 22 June 2018, 19:58

My guess is that some program noticed ram:disk.info changed and copied the file to the HD. Yes it did affect something on DH0.
If you want to avoid this the next time, the best way is to create some new dir in RAM: and then extract there.

Foebane · 22 June 2018, 20:21

Quote:

Originally Posted by meynaf

My guess is that some program noticed ram:disk.info changed and copied the file to the HD. Yes it did affect something on DH0.
If you want to avoid this the next time, the best way is to create some new dir in RAM: and then extract there.

Can I modify a script to create a temporary folder in RAM:? Maybe the startup-sequence? If so, I'm not sure where. Then I could modify Dopus to start in that folder and I'd be able to extract there, just like that, with the files isolated from the software as you described it.

meynaf · 22 June 2018, 20:59

Quote:

Originally Posted by Foebane

Can I modify a script to create a temporary folder in RAM:? Maybe the startup-sequence? If so, I'm not sure where. Then I could modify Dopus to start in that folder and I'd be able to extract there, just like that, with the files isolated from the software as you described it.

It's not difficult to create a folder before extracting...
Anyway you already have a temporary folder in RAM: that's created at startup. It's called T.

daxb · 22 June 2018, 21:06

If you really want to have a temporary directory in RAM: when using DOpus, then I would recommend to start DOpus from a script where you also create the directory in RAM:. E.g.

Code:

makedir Ram:mydir
DOpus
delete Ram:mydir   ; optional if you want to delete the dir when quit DOpus

I also thought about the Ram:T directory but you will have other files there sometimes.

Foebane · 22 June 2018, 21:18

Quote:

Originally Posted by daxb

If you really want to have a temporary directory in RAM: when using DOpus, then I would recommend to start DOpus from a script where you also create the directory in RAM:. E.g.

Code:

makedir Ram:mydir
DOpus
delete Ram:mydir   ; optional if you want to delete the dir when quit DOpus

I also thought about the Ram:T directory but you will have other files there sometimes.

Yeah, I thought the same thing, would be easier than what I suggested. I could also modify Dopus to start from that temporary directory on the right side. It would be neater. Thanks for the code, daxb.

Foebane · 23 June 2018, 05:50

I've got this working script, and along with starting DOpus in the new folder in RAM:, it's worked fine:

Code:

MAKEDIR RAM:DemoZone
ASSIGN DOpus: SYS:Programs/DirOpus4
SYS:Programs/DirOpus4/DirectoryOpus

I think having to have those two lines just to run DOpus is a bit much, however. But the Assign line IS needed, it seems.

Hewitson · 23 June 2018, 11:31

You should have the DirOpus assign in S:User-Startup.

Foebane · 23 June 2018, 12:10

Does it really matter? I have a couple of demos that need Assign commands, and I just assign them right there and then when I run them.

The way I have things, I can restore ClassicWB to a fresh install by simply overwriting the HDF, and I have a zip containing a patch which simply adds and/or replaces certain files, just so I don't have to set everything up each time. I really would like to change as few files as possible.

Thanks for the advice and info, all of you, anyway. The system is working fine, and better than ever. I cannot believe I was trying to use large HDDs to store the demos, when I simply needed a place to temporarily extract and run them. I don't need any RDB HDF files any more. I don't know why I didn't think of it in the first place.

daxb · 23 June 2018, 12:48

Where and when the DOpus4 assign is done is just a thing of preference. There exists a version of DOpus4 (4.17) that doesn't need an assign and has some features like long filenames.

tero · 23 June 2018, 13:28

4.16 doesn't need an assign either, but only when startet from wb. If you start dopus from cli it still needs the assign. I guess that's true for 4.17 too.

btw: ClassicWB copies the ram icon from the s: drawer.

daxb · 23 June 2018, 13:57

Quote:

Originally Posted by tero

If you start dopus from cli it still needs the assign. I guess that's true for 4.17 too.

Here it doesn't need an assign when started from CLI.

Hewitson · 23 June 2018, 15:02

Quote:

Originally Posted by Foebane

Does it really matter? I have a couple of demos that need Assign commands, and I just assign them right there and then when I run them.

Demos are only run very occasionally. Most people who use DOpus would run it almost every time the machine was booted.

What I'm getting at, is it would be nice to eliminate the script you're currently using to run it. It's simply unnecessary (as is a temporary directory on what is already a temporary drive!)

22 June 2018, 14:09	#1
Foebane Banned Join Date: Sep 2011 Location: Cardiff, UK Age: 51 Posts: 2,871	RAM Disk: Where are the files here stored? I've decided to use the RAM Disk for extracting archives to run the files from within them, and there is a Disk.info for the RAM Disk icon on Workbench, but at some point I extracted an archive that replaced the Disk.info with its own, and ruined the look of the Workbench. So what I'm asking is, where in the System HDD can I find the files that appear within the RAM Disk: device, to make backups?

22 June 2018, 21:06	#12
daxb Registered User Join Date: Oct 2009 Location: Germany Posts: 3,303	If you really want to have a temporary directory in RAM: when using DOpus, then I would recommend to start DOpus from a script where you also create the directory in RAM:. E.g. Code: makedir Ram:mydir DOpus delete Ram:mydir ; optional if you want to delete the dir when quit DOpus I also thought about the Ram:T directory but you will have other files there sometimes.

23 June 2018, 05:50	#14
Foebane Banned Join Date: Sep 2011 Location: Cardiff, UK Age: 51 Posts: 2,871	I've got this working script, and along with starting DOpus in the new folder in RAM:, it's worked fine: Code: MAKEDIR RAM:DemoZone ASSIGN DOpus: SYS:Programs/DirOpus4 SYS:Programs/DirOpus4/DirectoryOpus I think having to have those two lines just to run DOpus is a bit much, however. But the Assign line IS needed, it seems.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
disk.info (ram disk) - directory?!?	honx	support.Apps	38	21 January 2018 00:06
Listing files, loading files and allocating all available chip ram.	h0ffman	Coders. System	16	04 April 2013 21:24
Powering up a stored a500	MoreBITS	support.Hardware	8	07 December 2011 18:26
Where are icons stored in workbench?	gmiaow	New to Emulation or Amiga scene	8	11 December 2008 20:36
Newbie question: how to access files on an Amiga disk using PC disk drive?	Nethead	New to Emulation or Amiga scene	5	04 July 2003 23:07

22 June 2018, 14:10	#2
Predseda Puttymoon inhabitant Join Date: Mar 2007 Location: Tromaville Age: 46 Posts: 7,540	DH0:Prefs/ENV-archive I think? Not sure just now, but you can read it in DH0:s/startup-sequence.

22 June 2018, 14:28	#4
Predseda Puttymoon inhabitant Join Date: Mar 2007 Location: Tromaville Age: 46 Posts: 7,540	yes there is, and the folder is prefs/env-archive I believe

22 June 2018, 14:36	#5
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	Files in ram: are copied from envarc: (usually prefs/env-archive) at startup. So you can alter what you have in ram disk without any care - next reboot and everything will be like before. And you can just backup your hdd, no need to do anything special for ram:.

22 June 2018, 18:39	#6
Foebane Banned Join Date: Sep 2011 Location: Cardiff, UK Age: 51 Posts: 2,871	Are you saying that if the files in RAM: are overwritten and THEN deleted, they will be restored to normal upon reset from the ENVARC: backups? I tried deleting everything from RAM: and whilst the Disk.info and the single file in T were deleted, the folders were in use. Still, upon resetting, those files were restored. I'm just wondering why the RAM: icon stayed changed after the overwrite and upon reset - maybe because I hadn't deleted it? I can't see any files in ENVARC: relating to the RAM Disk - should I just remain assured that they're there and to count my blessings and leave it alone?

22 June 2018, 19:02	#7
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	Errh... do you know what RAM is ? Upon power up it is empty. So ENVARC: contents get copied to it. There is nothing to overwrite nor to delete. If your ram disk icon has changed permanently, then the file that got overwritten wasn't in RAM. It was somewhere in your HD. If it's copying some disk.info to ram: that changed it then some program monitors that change and saves that file somewhere. Default disk icon is normally env/sys/def_disk.info. Perhaps having a look there could tell more.

22 June 2018, 19:58	#9
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	My guess is that some program noticed ram:disk.info changed and copied the file to the HD. Yes it did affect something on DH0. If you want to avoid this the next time, the best way is to create some new dir in RAM: and then extract there.

23 June 2018, 11:31	#15
Hewitson Registered User Join Date: Feb 2007 Location: Melbourne, Australia Age: 41 Posts: 3,773	You should have the DirOpus assign in S:User-Startup.

23 June 2018, 12:10	#16
Foebane Banned Join Date: Sep 2011 Location: Cardiff, UK Age: 51 Posts: 2,871	Does it really matter? I have a couple of demos that need Assign commands, and I just assign them right there and then when I run them. The way I have things, I can restore ClassicWB to a fresh install by simply overwriting the HDF, and I have a zip containing a patch which simply adds and/or replaces certain files, just so I don't have to set everything up each time. I really would like to change as few files as possible. Thanks for the advice and info, all of you, anyway. The system is working fine, and better than ever. I cannot believe I was trying to use large HDDs to store the demos, when I simply needed a place to temporarily extract and run them. I don't need any RDB HDF files any more. I don't know why I didn't think of it in the first place.

23 June 2018, 12:48	#17
daxb Registered User Join Date: Oct 2009 Location: Germany Posts: 3,303	Where and when the DOpus4 assign is done is just a thing of preference. There exists a version of DOpus4 (4.17) that doesn't need an assign and has some features like long filenames.

23 June 2018, 13:28	#18
tero Registered User Join Date: Jan 2009 Location: M'Gladbach Age: 46 Posts: 621	4.16 doesn't need an assign either, but only when startet from wb. If you start dopus from cli it still needs the assign. I guess that's true for 4.17 too. btw: ClassicWB copies the ram icon from the s: drawer.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)