files not executeable

[GoogleCodeExporter]

What steps will reproduce the problem?
1.creating a HD directory (not a HDF)but a folder in WINuae on my SD card
2.Installing Workbench 3.1 from Cloanto Amiga Forever in the folder
3.launching WINuae adding my new folder and save config resetting and it boots 
up as DH0

What is the expected output? What do you see instead?
Putting my SD Card in the Wii, launching WII UAE via Wiiflow with IOS 249
and it won't boot it just says:"C;Setpatch not executeable"

What version of the product are you using? On what operating system?
WII UAE V11
WII V 4.1E

Please provide any additional information below.

Original issue reported on code.google.com by wiewa...@gmail.com on 6 Jan 2015 at 1:05

Attachments:

• code.txt

[GoogleCodeExporter]

Also all files on my DH0:Boot gets set to " ----RW-D " when moving my SD Card 
from my PC to my WII

Original comment by wiewa...@gmail.com on 6 Jan 2015 at 1:14

[GoogleCodeExporter]

Just today I found out the the SDL library, on which UAE Wii is based, loads 
the IOS 58 at start up, so it is useless to try use other IOSs.

Try also to put your files in /UAE/harddir and mount from the UAE menu.

Check if FastFileSystem file is in /UAE/roms

Original comment by olimpier...@gmail.com on 6 Jan 2015 at 7:48

[GoogleCodeExporter]

Okay Thank you. 
I'll be back with a follow up when i tried as suggested :-)

Original comment by wiewa...@gmail.com on 6 Jan 2015 at 7:59

[GoogleCodeExporter]

Hello again. 
It is not useless to boot Wii UAE from wiiflow  using IOS 249. 
Just tried to launch from  HBC and i could'nt get my mouse and keyboard to work 
at the same time, so i went back to Wiiflow and they both were working again;-)
Still the same problem with my file attributes. Right now i am using 
DirectoryOpus to set Datestamp to today and after that i set Protect to 
---ARWED for both harddisks. But wenn i reset the emulator all files show up 
with ----RW-D. 

Could it be something with Cloanto's workbench or kickroms?

Original comment by wiewa...@gmail.com on 6 Jan 2015 at 9:56

[GoogleCodeExporter]

I believe it depends on the emulator. I have to invistigate on it.

Regarding the IOS issue, which version of Homebrew channel are you using? Is it 
based on IOS 58?

Original comment by olimpier...@gmail.com on 7 Jan 2015 at 9:02

[GoogleCodeExporter]

HBC V 1.1.0
IOS 58 V 24.32

Original comment by wiewa...@gmail.com on 7 Jan 2015 at 12:11

[GoogleCodeExporter]

The bootpriority seems too low for a bootable partition.

Try:

filesystem2=rw,DH0:Boot:/uae/Boot,1

Original comment by olimpier...@gmail.com on 9 Jan 2015 at 10:02

[GoogleCodeExporter]

The virtual filesystem (harddir) has the disadvantage that it can not preserve 
the original file attributes as explained here:

http://www.amigaforever.com/kb/13-156

The executable attribute does not exist on FAT32 and therefore it is lost in 
the conversion from AMIGA filesystem to FAT.

You should use an hardfile to have executable files or use files associated to 
.info files.

Original comment by olimpier...@gmail.com on 10 Jan 2015 at 5:48

[GoogleCodeExporter]

Yes i see that now......Thank you

Using a hardfile now and it runs without any problems👍

I am using a16 GB SDHC card and have managed to create and mount 4 hardfiles 
(2.7 GB) for now. 

Adressing the issue (IOS, WIIFLOW and mouse/keyboard) i have no problems right 
now. 

I have a 4 port USB 2.0 in port 1 with the reciever for my wireless mouse and 
in port 0 i have the reciever 

for my keyboard. Also on my hub i have a 64 GB USB pen attached to run other 
emulators and it runs 

flawless

Original comment by wiewa...@gmail.com on 11 Jan 2015 at 10:28

[GoogleCodeExporter]

Anyhow the attributes not supported can be written in _UAEFSDB.___ file if the 
option filesys_no_fsdb is set to false.

htt p://www.amigaforever.com/kb/13-182

I have modified the code to fix this issue and adapt the Amiga filesytem to the 
Wii one (which is FAT)

Original comment by olimpier...@gmail.com on 11 Jan 2015 at 11:18

[GoogleCodeExporter]

In the new version (12), this is fixed. The attributes are correct now

Original comment by olimpier...@gmail.com on 23 Jan 2015 at 5:56

• Changed state: Fixed

[GoogleCodeExporter]

Super news. 

Thanks once again for your great efforts and splendid work

Original comment by wiewa...@gmail.com on 25 Jan 2015 at 6:51