Can my usb device have data on it already?

mediamogul

@cyperghost said in Can my usb device have data on it already?:

Then you're allowed to execute bash scripts even on linked fat32 device.

Very nice tip. I'll have to file that one away.

As I said, linking to the roms folder is just a neat solution and you don't have to be being a linux professional

That's a good point. Personally, I plan on maintaining my amateur status so I can compete in the Linux Olympics.

cyperghost

This post is deleted!

cyperghost

@mediamogul

Well I just tested for Quake and DOOM-builds as you maybe know.
With the bash-commands they work all flawless as linked FAT32 files.

Maybe a linux pro just taunts me now as noob because it isn't the pro solution but better suggestion are welcomed.

mediamogul

@cyperghost said in Can my usb device have data on it already?:

Maybe a linux pro just taunts me now as noob

I hope you don't think I was taunting you, as that was definitely not my intent. However, if you're also mistaking me for a Linux professional, I might have to roll with it and add the title to my business cards right next to "Bikini Inspector".

cyperghost

@mediamogul
No no... you were not taunting me :)
No problem

mediamogul

@cyperghost

Ah, good. I can still call myself a "Bikini Inspector" though, right? ;)

dankcushions

@cyperghost said in Can my usb device have data on it already?:

@mediamogul

ahhh yes.... I totally agree.
To avoid the fact that only with linking on a fat32 device the file permissions are gone and you're unable to launch bash files, then just edit the es_systems.cfgand add a bash next to the <command>y section. Then you're allowed to execute bash scripts even on linked fat32 device.

would this have a side-effect for people not using fat32/mapped drives? seems like a useful default if not!

As I said, linking to the roms folder is just a neat solution and you don't have to be being a linux professional :)

it's how I used to do it :) I think they're much the same in terms of results and number of steps. interested to hear from any "Linux professionals" as to what is actually 'best'

cyperghost

@dankcushions afaik as I know - No.
Because it does not matter how you execute a shell-script. I know 3 ways in doing this

chmod -x and direkt call via ./script.sh
bash script.sh
sh script.sh

Both sh und bash are shells. I do not know which one is better, but so far everthing is working as long as the sh or bash package is installed.

As you see FAT32 does not know file permissions, so you can not CHMOD a FAT32 script. Exceptions of this rule apply, if you do the mounting per fstab :) So I also think we can use this behaviour as standard. I am also sure this would work on NTFS, any UNIX-FS can be CHMODed. FAT32 gives the great chance to transfer huge files (ISO Images) directly to needed device by just plugging a USB-Stick to your PC.

mediamogul

@dankcushions said in Can my usb device have data on it already?:

I think they're much the same in terms of results

The only exception to this would be the elements in RetroPie that don't entirely reference the es_systems.cfg file for rom location. When any technical issues arise, it will always be a good idea to mention that this particular method of rom migration was used in order to expedite the troubleshooting process. As far as I know, these issues will only come up when using the Amiga emulators, BasiliskII, Daphne, DOSBox, ScummVM and possibly a few of the ports, but it's still worth noting.

dankcushions

@mediamogul can you be more specific ? which method has a problem with direct rom locations - mounting USB as /home/pi/RetroPie, symbolic linking USB as /home/pi/Retropie, or both?

cyperghost

@dankcushions Well I think he talks about the issues in searching errors via this forum.
There are several ways to change the location to the roms.

use fstab
change the es_system.cfg
use symbolic link

but you have always tell the forum members what you have done and what kind of file format on your usb-stick you are using. If there are some issues with the linking, then it will be the Amiga, Daphne, DosBox, ScummVM and Ports. I can only admit, that the Ports work flawless if you add to the es_system.cfg a BASH or SH command.

Usually 99% of the users use the Console Emulators so there are no issues and linking is an easy way in handling ROMS.

mediamogul

@dankcushions

which method has a problem with direct rom locations

Neither actually. I thought you were making reference to simply altering the es_systems.cfgfile, which I admit kind of surprised me. Both mounting and sym-linking an external roms folder to ~/RetroPie/roms should of course work in any situation imaginable. I misread an earlier post and was continuing on with the same misunderstanding here. Sorry for the confusion.

dankcushions

@mediamogul said in Can my usb device have data on it already?:

@dankcushions

which method has a problem with direct rom locations

Neither actually. I thought you were making reference to simply altering the es_systems.cfgfile, which I admit kind of surprised me. Both mounting and sym-linking an external roms folder to ~/RetroPie/roms should of course work in any situation imaginable. I misread an earlier post and was continuing on with the same misunderstanding here. Sorry for the confusion.

thought so :) that's fine.

to confirm, the only know downsides to the recommended method:

bash issue mentioned above (i'm still not sure that applies to direct mounting, or whether there's any side effect if it was a default for ALL retropie installs)
can't use internal symlinks on FAT32 drive (eg, the way latest advmame symlinks /RetroPie/roms/arcade/advmame/cfg/ to /RetroPie/roms/mame-advmame/cfg/(etc)

editing es_systems.cfg is not recommended for a bunch of reasons, but using a symlink is probably ok

cyperghost

Can we pin this post? Or add the symlinking inkl. bash to the wiki?
The info in this thread seems to be very valueable.

dankcushions

@cyperghost said in Can my usb device have data on it already?:

Can we pin this post? Or add the symlinking inkl. bash to the wiki?
The info in this thread seems to be very valueable.

personally i'd prefer we only have one method of mounting USB drives in the wiki so less to support. no point having two if they both achieve the same thing.