[Suggestion] File copy batch creator

[havor]

I use Primo Ramdisk Ultimate on a X79 64GB machine.

I use the RAMdisk for all programs that are always in use, like anti- virus, Firefox, and few others that are always in use and/or frequently used from disk, like the software is intended to be used.


But i also use the RAMdrive as temp quick disk, I use it mainly for games and heavier applications, as SolidWorks.

Every time I start a program, a batch file copies, the hole folder of a HD to the RAMdisk, and then start the game automatically.

It was lot of work to make the batch file, so for the files to start up with a minimum of work while using it.

How does it work with a batch file.

I use for all the temporary files that go on to the ramdisk a dedicated directory on it, and that i solely use for the temp program files on the RAMdisk.

How did i made ​​my batch file , and what steps are there in the batch file, and for each batch file, I only need to change the file location in the batch file.

Startup batch file

• 1 - Ask if the RAMdisk has to be used [Y/N] input.
  2 - If [Y], go to step 4.
  3 - If [N] Start file on standard way C:\FILE.BAT.
  4 - Display contents of the temporary folder, and displays total and spare disk space of RAMdisk with /dir command.
  5 - Displays size of folder that get moved to RAM disk.
  6 - Ask for [Y/N] input if other folders need to synchronize, and then removed from RAMdisk.
  7 - When [N] go to step 9.
  8 - When [Y] start standard remove batch file C:\clean.bat.
  9 - Wait for user input (Any key) during file removel /pause.
  10 - Copy the folder of local (or network) drive to the RAM disk.
  11 - Start program on the RAM disk.

Synchronize and removed from RAMdisk with batch file. (clean.bat)

• 1 - Mirroring files with Robocopy, for each folder I have in the clean.bat file and start a separate Robocopy command to synchronize the folder to a folder on the HD, the RAM disk . ( not reliably on XP machines because of a bug !)
  2 - Remove contents of the folder.

Synchronize and removed files from RAMdisk batch file during reboot/shutdown. ( clean.bat )

1. Of course, during a reboot or restart also want your files are synchronized , how to do it, read it here.

Why Robocopy , Robocopy is the most comprehensive copy and mirror task that has Windows , and my goal is to mirror / sync feature is ideal , since only the files that have changed are copied , and so really it happened very quickly , well below the average 5sec .

The Advantages and Disadvantages, for my setup anyway.

• + Can really be much faster than SSDs.
  + Steam has no limits anymore. (but that counts also if you temporarily move your games, its just a lot more work)
  + feeling wise, i have a much faster system when i use the RAMdisk.
  
  +/- Very long file starting time when moving files via network to RAM disk, but after quickly, and still better than getting on a new install or manually copy the archive directory.

Got some great copy time improvements over the network using non and medium compression with the WinRAR command line, as you then only transfer one big file, but then you cant use mirror function of Robocopy anymore, and ads up to wait time if you have to free up space on the RAMdrive

• - Expensive!! (X79 + 3930k + 8x8GB RAM, but for me personally it's worth it)
  - Longer file start time while moving files to RAMdisk, specially from network drive.

The Suggestion.

Even do the batch file i made works sorta fine, i am no programmer, and a file launcher, shortcut creator would be a hell of a lot better, something like the Deamon-tools ISO mounter.

How should it basically work?

Click on program shortcut/settings file > move complete folder to RAMdisk > start program on fast RAMdisk > sync changes wile or after running program.

How should it work for making the batch/settings file

• Start the launcher/batch-maker.
  Look for a folder with installed program eider on disk or on the RAMdisk installed in the dedicated temp program folder.
  
  If installed on the RAMdisk, set a destination folder for permanent storage.
  Select executable that needs to be started after folder moves to RAMdisk.
  Set minimum free space on RAMdisk after program launches. (some programs need a lot of space storage space for temp files, others uses very little)
  Create batch/settings file with how the file should launch.
  
  If on normal storage
  Select folder
  Select executable
  Set minimum free space on RAMdisk after program launches.
  Create batch/settings file with how the file should launch, including icon.

How should it work, starting a program whit a batch/settings file

• Click batch/settings file
  File sends info and setting to launcher
  Launcher asks if you wane use RAMdisk or launch normally. ("don't ask again" option for turning question off)
  Launcher checks how big folder is and checks if there will be enough free space is left, as of given in the value in settings file.
  If enough space free copy folder to RAMdisk and start program.
  
  if not enough free space
  Ask user what folder/program he wants to sync with folder on permanent storage and remove from the RAMdisk.

If anyone thinks i made a mistake or think it could be improved some ware, pleas post your idea's and opnions.

• Think for Romex doing this could also be a great marketing stunt, by sending licenses to hardware and game review sites.
  And for home users they could make this a $5 or $10 option for the Standard and Pro Edition licenses.
  
  Like the with the Standard Edition, you can still only use 8GB for files that are always on the RAMdisk, but give people the option to load more then the 8GB and use the RAMdrive manually true the launcher.
  
  It will almost certainly also not eat in to Pro and Ultimate Edition revenue, as they want to be loaded permanently on the RAMdrive, and the function can be removed from the Standard and Pro Edition for Business License model.

ps. sorry my English is far from perfect please bare with me.

[CrypEd]

Copying all the data into a RAM-disk by explorer-script-shell-extensions? :p OMG
... a new Bluescreen-"Gate".

Why not you move your data inside of the RAM-Disk, redirect NTFS to your Ramdisk and save the Image somewhere on your disk?
I guess with 64GB-Ram, you don't have a SDD-storage-size-problem either.

See there's a reason "Image"-files exist :p

So you can load/unload your specific Image with few clicks and simply start your Shortcut... and manually save it with few clicks too.

I dont think your idea is of any proper use, sry.

[CrypEd]

Oh and BTW: This function already exists in explorer. It is called "send to".

So select the data you want to move, right click, choose "send to" > RAMDISK (X:\).
It warns you for example if size is to high.

But what it does is copying... so the application will still open the files from original directory.

So you save your RAM-Disk to an image and you tell NTFS that the folder is now symlinked to RAMDISK.

I don't think it is good for Primo as a project to start struggling with shell-extensions and managing such "send to" or "send back" automatically on their own. I hope they make the write-L2-hotswapp beeing perfect, thats more important IMHO.

[CrypEd]

Another thing is that you can do all that you explicitely want for your very own with your script:

http://www.romexsoftware.com/en-us/prim ... rface.html

Command Line Syntax

rxprd <command> [<option>...]

<command> Specifies a Primo Ramdisk command (see command list below).
<option>... One or more options that modify a command.

Command List

ls Lists all virtual disks.
add Creates a new virtual disk.
del Removes a virtual disk.
view Displays the settings and status of a virtual disk.
edit Changes the settings of a virtual disk.
rebuild Recreates the disk with new settings.
init Reinitializes a virtual disk.
save Saves the disk contents to an image file.
export Exports the disk settings as a disk descriptor file.
...

For detailed command and option information, type:
rxprd ? <command>

So instead of copying data from the ram to disk and backwards by scripts, demanding ridiculous stuff:
Why not you easily adjust your scripts to take use of RAMDisk-Images and NTFS-Symlinks?

Heres the idea for your scripts:

1. script loads an ram-disk-image.
2. script renames original-directory.
3. script creates a symlink with original name linking to the RAM-disk.
4. script invokes specific application start.
(5. application close invoke script continue.)
(6. script saves-image to disk optionally)
(7. script optionall copies files to the "renamed"-original-backup-folder, too)
8. script unloads the ram-disk image.
9. script removes the original-named symlink.
10. script renames backup-folder back to oirginal-name.

You pretty dont need that if you want your application to be always run from RAM, in that case you once setup an image, remove the original data, symlink the original folder and do this in script per app:

1. Load image
2. Start App
3. Unload image

Simple as that! This also gives you the possibility to move "big-data" images to anywhere you want...without touching the installation path on i.e. C:\.... like you can install 100 10gb games on a 100gb-SSD just by moving the Images containing the big data of 91 not so actually used games of them quickly moved onto a HDD. That's awesome possibility.

But sometimes you don't want it to be unloaded just because it closed..maybe you want to re-open right after... all depends on your use-case. It is not clever trying to automate this at this state of developement.

If you need scripts, then you are free to proceed...that's what CLI is meant for.

[InquiringMind]

This idea (and CrypEd's modifications to use junctions/links) very closely matches that in the Ramdisk Folder Migration thread.

I'd agree that this shouldn't use the Explorer shell (just imagine how much fun there'd be if someone accidentally "mirrored" their system folder?) and that symlinks/junctions would have to be used to avoid drive/folder name changes (which might require configuration file/registry changes). But if done in a robust fashion (note that the original folders have to be renamed to avoid conflict with the links) it could make ramdisk usage much easier.

[havor]

I agree that my script is certainly not the most fashionable way of doing tings, that's why i ask Romex, if they wane make a folder mounting system, ware i can store my data on a non volitional disk, and click a icon/shortcut and move the files and start the program.

How they make it work i really don't care, as long as its easy to use and users don't have to use a script, but can just click true a menu to make them, as my script is mostly copy/paste work from Stackoverflow.com, as i have just a rudimentary understanding of it.

Pretty sure guys that can make RAMdisk software, can make a better solution then me.

[CrypEd]

Well I encourage you in improving your scripts and share it.

I think the biggest problem is that people using RAMDisk in unique ways. All these masses of available function may only fit into a particular specific use-case perfectly. The actual state is that you (should) need to know what you are doing with every setting of your individual single task, otherwise it may be worthless or more badly runs into systematic-failures.

So it is pretty hard for the developers to integrate all of it in an automated GUI.

Still with some BATCH-Skills and RTFineM of RAMDisk CLI you can do almost any automation you want.

So with some variables and some comments, some of those script-templates could really be a "nice-to-have" for everyone to reduce time for work setting up RAMDisks significantly.

Just copy the .BAT to your App-Folder...rename it to Exe-Name, change some variables in the top of the script to fit the application folders and the use-case RAMDisk settings and script-settings, replace Exe with Bat in the shortcut and go go go.

It is also possible to hide the DOS-Boxes ^^

[CrypEd]

1. script loads an ram-disk-image. (rxprd-CLI) <--- variables at top of script / configuration comment: ram-settings (size,type,drive-letter,etc)
2. script renames original-directory. <--- variable at top of script / configuration comment: data-folder. RN
3. script creates a symlink with original name linking to the RAM-disk. <--- using original-directory-variable and RAM-drive-letter variable
4. script invokes specific application start. <--- variable at top of script / configuration comment: application executable
(5. application close invoke script continue.)
(6. script saves-image to disk optionally) <--- variable at top of script / configuration comment: Save on close? If boolean variable > rxprd.

(7. script optionall copies files to the "renamed"-original-backup-folder, too) <-- variable at top of script: / configuration comment: Update original-folder on close? If boolean variable > copyall ...

This is far more problematic, do you want to remove original (full replace incl remove of deprecated) or do you want to copy everything over and just replace (so you might keep old files that are no more "original" if names of files change, i.e. game-update). So more likely you want to full remove, then full copy - for a perfect copy, but what happens when you run out of power in that moment ^^... all gone. So you need to extend Step 7 to rename old-original-backup again, then re-copy back the "actual-original" from RAM, when finished, remove the old one....problem is this forces you to keep 1x the space for the image and 2x the space for the folder..so your disk-usage for the App will triple-spike on every close....

8. script unloads the ram-disk image. rxprd.
9. script removes the original-named symlink. rm.
10. script renames backup-folder or the updated (step 7) "original-folder" back to oirginal-name. rn.

You can still manually save the image in any case after a app-update at any moment (considering the update ran without problem on your limited RAMDisk-task-space) and one is not to use automation Step 7 . . .which represents a huge IO-task...everytime, not all the times for any reason at all...depending on the use-case.

Anyhow... you might not want to unload on app-close ^^, in that case at some point the "automation" runs into problems when RAM-Usage exceeds max Furthermore problems happen when your disk is full. xD

I doubt Romex will provide a "Full Automation" system for such in the near future... since providing such scirpt/app-integration into RAMDisk (maybe Explorer) consumes lots of effort... as I said because of the diversity of RAMDisk ... or lets say "the power" of the Romex-product.

But please see how copies files complicates things. The hole scripts gets a lot easier if you only use the RAM-Disk-Images and remove the original folders completely. Sure that way the App isn't available without the RAM-Disk running. But it more save, more compact and faster in any matter!

So if you need any help with your scripts in specific, just tell it...

[havor]

1. script loads an ram-disk-image. (rxprd-CLI)

Dose that way not in tale that you have to work with multiple drive letters, if you wane have 2 or more program maps cached on a memory RAMdrive?

[CrypEd]

Not exactly, if you use 2 apps on one RAMdisk then you would need to load the hole RAMdisk for any of both Apps running... you just change the variable in the "wanted" script to Point to the Image, give it the appropriate size and tell it which drive letter, same in both scripts for both apps if both use the same image, simply as that.

When you launch your second-app script with the same drive-letter, rxprd cannot create, but glad we have silent mode, so the script then continues, the step is just skipped and the app simply starts... no more adjustments needed. The step to load the same RAM-Disk image is obsolete while it is already loaded.

Sure you need to manually tweak such settings in an dynamic environment to fixed values...thats what script-headers are meant for.

You just copy the script in, change ~10 variables once per hand.... re-edit your shortcuts to the invisibilised-BAT and forever only do the standard double-click on your desktop-icon and it does the work "automated".

To this day you manually go into Primo-GUI, create a new task, load from image, specify load&save-option and start... considering your symlink is already configured...now you can doubleclick your application... thats lots of time wasted!

Nobody talked about inventing a KI that decides for the user... i guess this thread is about automation scirpts/GUIs, that reduce work creating ram-disks.... like you can configure "templates" about how to create a Ram-DIsk and what else to do in the system.

Sure unloading a RAMdisk on app-close, that another app also relies an will run into problems. You are right, so maybe you would need another variable:

Unload on close?

The more you think about automation, the more problems pop up.... thats exactly what i am talking about