Confusion using scripts with an USB drive connected

Hello, i’m sorry i’m asking for a little help for an issue i have that i can’t figure out :

when i try to make a script that uses the SD card and the USB drive at the same time, i’m stuck… i know that the /usbdrive folder is in the SD card, so if there’s no USB drive it will attempt to read/write there, but when an USB drive is connected it looks like scripts consider the /sdcard as a path within the USB drive, can i specify to use both in a same script…? thanks! :v:

True, /usbdrive is just a folder on the SD card but it serves as the mount point for the first (or perhaps most recent, I’ll have to double check) drive mounted. The drive is mounted on startup (if connected) or when you select ‘Reload’ from the storage menu…(although you probably knew all this)

I’m not sure I follow… you should be able to have a script that manipulates things both in /usbdrive and /sdcard, i.e. something that backs files up to a USB drive

1 Like

thanks! that was exactly what i was trying to do, in fact it was something else wrong in my script… but when i try to run an installer from the USB drive to the SD card, it always installs on the USB drive even if i try to specify USER_DIR:="/sdcard" in deploy.sh (there’s no /usbdrive mentionned in it…), should it be possible too ?

this is as expected…

there are two steps to installation of a zop:
unpacking the contents (including verification of integrity)
running the deploy script (for post install configuration)

it always unpacks to the ‘current user dir’

to do what you want to do, you could make deploy.sh move the patch afterwards
(you’ll see i do this for quite a few system scripts , where I move things from /Patches to /System, its the same principle)

however, some caveats:

a) organelle-1
/sdcard is only for patches, and will not exist for many organelle-1 owners.
(this was introduced only in 3.x, and was optional , since its only possible with a larger sdcard than supplied)

b) is it desirable?
the current method, means that the usb stick can be used for ‘different setups’ - this is why it completely overrides the ‘user dir’.

c) will it make sense to the user?
because of (b), if you take the patch from the usb drive and put it onto the sdcard,
the user will not *see the patch in the patch menu until they eject the drive.

Im not quite sure why you are wanting to do this… but on the surface I think it could lead to confusion.


thats not to say I don’t think there is isn’t some room for improvement here - but I think it should be in the core OS/mother host.

the current sdcard support is really built around using wifi to manage, as this is the mechanism I use.

however, I did mean to add some support on the organelle for managing sdcard <–>usbdrive.
primarily so that a user could use a usbstick to install to the sdcard, when they did not have wifi.
(which i wonder if this is what you are trying to do?)

I can see 2 things that could work well.
A) install target
the organelle, could detect the usb stick being inserted, and see a zip/zop in the root directory. and then offer to install that to the sdcard. - in this ‘mode’ the user is not mounting the usb stick with reload, so its not see as a ‘user drive’

B) sync usb
this would allow the sdcard to be synchronised to the usb stick.
potentially this is useful for:

  • backup
  • re-organising the sdcard patches without a computer.

I was going to put this in when doing 3.x, as its a simple rsync, but there’s a couple of ‘issues’

  • its going to be pretty slow, as the usb read/write speed is not that fast, this means really you want some kind of user feedback.
  • sync’ing is never perfect, whats the strategy?
    who is the master? e.g. if I see a patch on the sdcard but not on the usbdrive… should I copy it to the usbdrive (sd=master) or remove it from sdcard (usb=master)
    and you can’t really just ‘make the user choose’, because they quickly get confused about the process.
    and to make matters slightly more complex, file dates and times are only reliable if organelle had a network clock source.

upshot is… I think
(A) Would be really useful for some, and is pretty simple to do.
(B) I’m not so sure about, it could lead to more confusion than solving problems,
but perhaps two simple options ‘Sync FROM usb’ ‘Sync TO usb’, might work.

I do think they are both valuable additions to the mother host, as I think quite a few are still using USB sticks… and it be great to migrate more users over to the SDCard as, imho, its a much better experience and also more reliable.
(note: as above, I think keeping current usb functionality as user drive is very useful for ‘different setups’)

I understand, thanks a lot for these informations! :pray:t2:

I wanted to know because i intuitively want to use USB to :

  • install patches onto the SD card without needing wifi or mouse+screen
  • back up files from SD to USB and restore them from USB to SD

I only have the Organelle M since 2 months so i’m not used to the way it was working before (/usbdrive as main folder), i know and understand why it was working like this (and so why it’s working like that now) but i prefer to use a bigger SD card and only use USB optionally.

Thanks to you now i know that all the works i released is for the M only because i always specify /sdcard into my scripts and patches, unfortunately for Organelle-1 users i didn’t know that it was optional… (but i didn’t get feedback, maybe it works anyway…?).

I like your Sync idea, but i guess it’s not that simple too, i worked on backups scripts to let us archive on demand (/Patches for example) within the SD card and restore without removing new content added post-backup (it’s like copying a old folder onto the new one : existing files are overwritten, new files stay). I would like to make it to work over USB but it’s problematic for restoring as (if i understand correctly) we are not actually able to copy from the USB to the SD card with a script.

“Install target” as you mentioned would be perfect i think, or maybe an option to set and fix the desired USER_DIR manually in the settings…?

:v:

there is no reason a script could not (attempt to) mount the usb stick, if you wanted to do this. though should then unmount after you have finished, otherwise many things will assume you want to then use it as the user driver.

yeah, this seems like it would cover most users requirements of using usb drivers to transfer patches - without causing additional confusion.

1 Like