xyAutoMounter

[highend]

Actually, it doesn't mount anything

This solution is portable (unlike USBDLM)
You should use it's own directory for it (don't put it directly in <xyscripts>)
Unless I implement self elevation, use a non restricted (e.g. by UAC) path!
If you want to use it with an elevated XY instance, you have to start it with admin permissions (yourself)
It tries to execute the script(s) for all open XY instances!
ATM, this is in beta, it could burn your PC, destroy your relationship, be warned!
This is the first beta so expect bugs!

What it does?

When you insert / remove a removable media (e.g. an USB Stick) it will execute a script...

Two scripts are included, "Connect.xys" and "Disconnect.xys".
Connect.xys will add the drive letter to the tree (even for locked trees) and open a new tab with the drive as the target path
Disconnect.xys will remove all tabs (in active & inactive pane) that refer to the mounted drive letter and remove the entry from the tree

On first startup an .ini file will be created. Default entries for Connect / Disconnect will be set.

This .ini file understands "rules"
Each rule must begin with a number (beginning from 1, 2, ..., n), followed by "=" and then you can use either
- The drive letter / the serial number for that media
followed by an "|", followed by an absolute / portable path to a script

For example:

[Connect]
Default=.\Connect.xys
1=X|.\Connect_Drive_X.xys
2=Y|.\Connect_Drive_Y.xys
3=8EE7-0231|.\Connect_Drive_With_Serialnumber.xys

You can look up the serial number of a removable drive by going to the "Computer" node in XY.
The column "Vol Serial" contains the belonging serial

The order for the entries in section "[Connect]" or "[Disconnect]" doesn't matter, the "Default" entry is always checked last,
the numbered entries are checked in ascending order.

The first match wins!

Any script you use must begin with:

Code: Select all

perm $P_AutoMounter_Drive;

and you must refer to this variable to use the drive letter in that script. In doubt check the included scripts...

I didn't expose a drive's serial number as a permanent variable (don't know if this is really necessary atm)

Todos:
- Implement self elevation when necessary
- Implement auto-reloading of the config file when the .ini is changed externally
- Remove the tray icon when it's getting stable
- Design it's own icon

Current version:

xyAutoMounter_v0.0.0.1.zip

(396.38 KiB) Downloaded 303 times

[highend]

<Reserved>

[bdeshi]

Nice idea of integrating portable drives with XY.

I haven't actually tried this yet, just curious

you can use either
- The drive letter / the serial number for that media
followed by an "|", followed by an absolute / portable path to a script

Is the portable path relative to these scripts or the relevant drive? If it is/were relative to the inserted drive, then this creates an unbreakable tie between each drive-script set!

[highend]

The path that acts as the "root" for ".\" is always the folder where xyAutoMounter.exe is in.

So, e.g. if you'd create a folder "<xydata>\Scripts\xyAutoMounter" (and put xyAutoMounter.exe in there),
".\" refers to that folder...

[bdeshi]

well then can you make relative paths relative to the drive root? Just an idea.

[highend]

Sure, wouldn't be a problem.

But... Do you think that people would actually want to store the connect.xys file on those drives?
This would be like the current autorun implementation for usb drives when a file called "Autorun.inf" exists in the
root of the drive (with the difference that this would allow to place the "Connect.xys" anywhere (even inside folders))...

This wouldn't work with "Disconnect.xys" files though because when xyAutoMounter kicks in after the drive has been
removed... (although it would be possible to automatically copy the assigned "Disconnect.xys" file to a temp storage
and execute it from there after the drive has been removed...)

Thoughts?

[bdeshi]

The main advantage to this feature is that it's completely drive-letter independent, like volume serials.

This would be like the current autorun implementation for usb drives

Exactly. Except there's none of the security issues here. (You can always let users [or automatically] save the hash of "drive-relative-pathed" scripts in the ini file to warn against tempering.)

At the end, it's just one more choice that could be useful to some.

[klownboy]

Hi highend, I hope all is well. I 've been putting this through the paces and it seems to be working fine. At least once I disabled the USBDLM service. USBDLM was definitely interfering with it especially since I have XY scripts tied to it. I'll have to decide on its use though versus USBDLM. Of course, USBDLM works across the board (in and out of XY), but the question is do I really need it across the board.

Initially it wasn't automatically adding the tab when I inserted a flash drive and I believe it was due to the fact that I had made changes to the ini after the initial run of xyAutoMount. If changes to the ini require a reload of xyAutoMount, you may want to mention that. I did test with both the Volume Serial and the Drive letter and it worked fine. As far as removal of the drive, typically you shouldn't just pull (physically remove) a drive unless it's been "safely removed" first. Is xyAutoMount safely removing the drive if I actually physically remove it, or is the proper way to invoke xyAutoMount by running the Disconnect script via a CTB or similar? I ask because I did just pull the drive and via stepping could see that the Disconnect script was invoked, but that doesn't mean it was "safe" to do so. If it wasn't safe would it let me know or disallow it?

The whole idea with this is to have the flexibility to change the scripts based on the external drives being connected or disconnected or use a default action which is great. I've taken the time to "name" all my external hard drives and flash drives for use with USBDLM, balloon tips, tab names, etc. I imagine I could take advantage of the named drives and use that in the tab name as I do with USBDLM and my associated scripts. Thanks.

[highend]

At the end, it's just one more choice that could be useful to some

Ok, I'll add that

At least once I disabled the USBDLM service

I could "disable" xyAutoMounter when it detects that that USBDLM service is running if necessary...

If changes to the ini require a reload of xyAutoMount, you may want to mention that

Atm that's the case. This is mentioned in the first thread in the Todos: list

If it wasn't safe would it let me know or disallow it?

xyAutoMounter doesn't do any mounting or dismounting by itself. It just monitors the list of connected (removable) drives and starts scripts when one is added / removed. Since this is done by the user xyAutoMounter is "safe" to use

balloon tips

That's my next feature request: A script command that allows us to display a balloon tip on XY's tray icon (something like the status sc...)

[klownboy]

xyAutoMounter doesn't do any mounting or dismounting by itself. It just monitors the list of connected (removable) drives and starts scripts when one is added / removed.

So if I decided to use xyAutoMounter in lieu of USBDLM, would it be a good idea for me to utilize Uwe Sieber's other non-resident utilities like RemoveDrive and RestartRsDev? Especially since I currently use both of these utilities in my XY scripts in conjunction with USBDLM. As you already know, RemoveDrive prepares drives for "Safe Removal" (by commandline) and RestartRsDev will restart a device not physical removed. I could run statements like this (changing the variable to match yours) in the scripts to ensure the drive is safely removed or wake it up to restart it.

Code: Select all

run """D:\Tools\RemoveDrive\RemoveDrive.exe"" $drive_letter", , 2, 0;
run "cmd /c ""D:\Tools\RestartSrDev\RestartSrDev.exe"" *", , 2, 0;

I have a CTB setup on left click which will wake up an external drive which has been safely removed but not physically removed, and the CTB on right click will remove the drive. I should be able to do the same using the utilities with your program/scripts. The key for me to decide is still how much do I use or take advantage of USBDLM outside of XYplorer...I'm thinking not much really. Thanks.

Gotta love those balloon tips.

[highend]

So if I decided to use xyAutoMounter in lieu of USBDLM, would it be a good idea for me to utilize Uwe Sieber's other non-resident utilities like RemoveDrive and RestartRsDev?

I use them as well to start / stop external drives or unmount / remount usb sticks on my system but this is not about xyAutoMounter
How you unmount / mount a removable drive isn't of any interest for xyAM. It's not involved in this process. It just executes script after these "steps" regardless if they were triggered by the user or the OS.

Look at it like this:
If you use RemoveDrive from a CTB, xyAM will react automatically as soon the OS has confirmed that the drive isn't available any more. The same goes for RestartRsDev

[klownboy]

It's not involved in this process. It just executes script after these "steps" regardless if they were triggered by the user or the OS...If you use RemoveDrive from a CTB, xyAM will react automatically as soon the OS has confirmed that the drive isn't available any more.

Ok thanks highend for the clarification. That is what I suspected, but wasn't positive.

[eil]

interesting project. =) though i didn't really get how it works.. the utility sits in ram and when new usb-drive is connected opens it in XY? and after unplug closes tabs that are pointing to already unavailable flash, right?

[highend]

and when new usb-drive is connected opens it in XY?

That solely depends on what script you execute. If you use the default settings
my description from the first post stands:

Connect.xys will add the drive letter to the tree (even for locked trees) and open a new tab with the drive as the target path
Disconnect.xys will remove all tabs (in active & inactive pane) that refer to the mounted drive letter and remove the entry from the tree

The scripts can do whatever you want them to do (by modifying the default scripts) or e.g. by changing the .ini file (and load e.g. a specialized script for a specific drive letter)

Btw, the next version does include auto reloading the .ini file when you change even while xyAutoMounter is already running...