Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
103 user(s) are online (52 user(s) are browsing Forums)

Members: 0
Guests: 103

more...

Headlines

 
  Register To Post  

« 1 (2) 3 »
Re: usb 16go key copy problem on SAM
Quite a regular
Quite a regular


See User information
@ZeroG

The key has been formated as FAT32 with AOS4.1. Take now a verry long time to be initialized by AOS (key led flicker during a long time).

after formating by AOS4:
L:crossdodfilesystem (FAT2)
used: 9.3 go (62%)
free: 5.6 fo (38%)
size: 14.9 go
block:512 octets

A verry strange formated result by OS4. This key work without problems with a PC usually. It's why I have the problem to said It's a faulty Key and must be remplaced because no problems on a PC (key used often at job or on the classic+spider2).

I think I will full this key with the classic+spider2 for checking where came the problem

to be continued....


Edited by Mrodfr on 2009/5/21 20:00:01
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: usb 16go key copy problem on SAM
Quite a regular
Quite a regular


See User information
@all

Just for resurrected an old thread (but just related to USB and SAM).

Sometime copy USB stop strangely. This time a memguard hits when copying a file to a Memory stick adaptator.

The hit came and dopus4 PPC stop to copy. just reboot the SAM.

SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()
SFS: Warning: Task 0x5fe9a010 ("OHCI Controller Task Unit 0") called DoPkt()

MEMGUARD HIT - "OHCI Controller Task Unit 0" (5fe9a010)
allocation of 32768 bytes by AllocVecTagList() failed
0: 6f8c2be4 5fe86e00 00000000 01c997c4 00008000 5fe86e88 80000005 80000003
8: 80000002 00000008 80000001 ffffff80 80000004 00000000 00000000 00000001
16: 4b421148 01e70000 5fe6b680 00008000 5ff99200 01e70000 ffffff0e 00000040
24: 4af6c508 00000003 00000000 00000000 00000040 00000001 00000001 00000080
----> 6f8c2be4 : "MemGuard" segment 0005 offset 8bdc
----> 01c997c4 : "Kickstart/kernel" segment 0001 offset 497c0
LR 01413690 : "Kickstart/kernel" segment 0000 offset 1368c
CTR 6f8c2be4 : "MemGuard" segment 0005 offset 8bdc

Stack backtrace:
----> 01413690 : "Kickstart/kernel" segment 0000 offset 1368c
----> 018b29dc : "Kickstart/ohci.usbhcd" segment 0000 offset 3bb8
----> 018b178c : "Kickstart/ohci.usbhcd" segment 0000 offset 2968
----> 018b5674 : "Kickstart/ohci.usbhcd" segment 0000 offset 6850
----> 018b59f8 : "Kickstart/ohci.usbhcd" segment 0000 offset 6bd4
----> 018b4508 : "Kickstart/ohci.usbhcd" segment 0000 offset 56e4
----> 0141581c : "Kickstart/kernel" segment 0000 offset 15818

Disassembly:
0141368c: 4e800421 bctrl
01413690: 80010084 lwz r0,132(r1)
01413694: 38210080 addi r1,r1,128
01413698: 7c0803a6 mtlr r0
0141369c: 4e800020 blr


It's just because I don't know how reporting this problem to AOS4 developpers. Hope one of them will see this post.


EDIT: Why allocated just little 32768 bytes for buffer (IMHO). We have 512mo of memory, or more


Edited by Mrodfr on 2009/11/8 18:08:17
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: usb 16go key copy problem on SAM
Just can't stay away
Just can't stay away


See User information
@ZeroG
Quote:
I think that i dont know more than you.

I know two things.
1. OS4 Dopus4 link handling is broken. Use Drag'n'Drop on WorkBench to make large copies that may have links. AsynWB seems to handle links and large copies with nested directories much better than Dopus4.
2. Copying Amiga files to a Fat32 formatted device of any kind is problematic. Amiga file names can contain characters that are illegal in Fat32. I only copy individual files (one at a time) for a Fat32 formatted USB stick, which works. I have formatted my 16GB USB memory sticks with SFS filesystem and can Drag'n'Drop entire partitions to the USB stick with no problems. Such copies seem to take forever because of USB1 speeds but nevertheless it works.

Go to top
Re: usb 16go key copy problem on SAM
Quite a regular
Quite a regular


See User information
@xenic

Quote:

xenic wrote:
....Amiga file names can contain characters that are illegal in Fat32.......


Do you know the illegal caracters...

BTW, no problem at all with poseidon/AOS3.x.

A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: usb 16go key copy problem on SAM
Quite a regular
Quite a regular


See User information
@all

Hum, I like this particular personnal thread, just for the USB problems I could have.

On my OCZ rally, I have copied AOS4.1 inside long time ago. one week ago, I have choosen to delete the copy located on the OCZ rally key, on the SAM. All have been well deleted but only:

DH1:utilities/sgrab/catalogs/aeeetina

hasn't been deleted (the path just with 0 size but on the key).

Ok. Some days ago, I have tried to use the key on a PC at job and the key has not been recognized on the PC.

This morning, I have used poseidon on the classic and the key work fine. try to play with aeetina (try to delete or rename or other things without luck). I have also copied some picture I have on the key safely on the classic (the only one who continue to recognize the key well).

OK, I have after copied one file on the key and... strangely, the name become 8+3.

hum, refresh the key content with dopus and all the key contend become 8+3 and with strange size. Again another time.

All this explanation to say that I have found that on sgrab, the langae aeeetina drawer (of course, sould be witten with the exact caracters langage) could lost you the content of your fat95 medias on particular conditions.

This time, the problem began on SAM, media not work on PC and finally, I have killed the usb content with the classic+poseidon

just for your information, be carefull with strange caracters on your SAM files installation.... could be destructed if copied on fat medias...

Bye.

A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: usb 16go key copy problem on SAM
Just can't stay away
Just can't stay away


See User information
@Mrodfr

Dont forget that all your data is going through crossdos which is not the most reliable program I've ever used. I don't know how well it handles soft links.

For a quick solution to your backup problem I suggest using AmiDVD to create an iso image and copy the single file to the usb stick. You can then use diskimage to mount it directly from the usb stick to access any files you need.

Amiga user since 1985
AOS4, A-EON, IBrowse & Alinea Betatester

Ps. I hate the new amigans website. <shudder>
Go to top
Re: usb 16go key copy problem on SAM
Quite a regular
Quite a regular


See User information
@Severin

At least, he not like: ?e?tina drawer on sys:utilities/sgrab (but as you could see on this whole thread, this ?e?tina arrive just now).

Do wee keep the crossDOSfilesystem as ever on the AOS4.x ???

FAT95 on 68k, even if chris hodges said he has problems, if for me a lot more reliable on AOS3.x than crossDOS on OAS4.x !!

QUestion:

- CrossDOSfilesystem has been improved a lot for AOS4.1.1 (please AOS4 betatesters, answer this question) ???

If not A bounty is urgently required to have good FAT support on the Amiga IMHO.

This is a point I will quicky talk again after AOS4.1.1 release..........

A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: usb 16go key copy problem on SAM
Just can't stay away
Just can't stay away


See User information
@Mrodfr

It was said several times on other topics the crossdosfilesystem bugs have been fixed. So i really hope copying files to usb will not corrupt with the os4 update.

Go to top
Re: usb 16go key copy problem on SAM
Home away from home
Home away from home


See User information
@Kicko

Let's hope so,atleast for sam users. hehe

X5000
Go to top
Re: usb 16go key copy problem on SAM
Quite a regular
Quite a regular


See User information
@All and kicko,

Have tested my brand new (return warranty) OCZ Rally2 16gb key with AOS4.1.1.


First was to copy all WB content to the key, as a first test. Choosing the wb content and the copy start fine. Some 100mo copied and suddenly a crash, catched by memguard:


MEMGUARD HIT - "OHCI Controller Task Unit 0" (5fe5a070)
allocation of 8192 bytes by AllocVecTagList() failed
0: 6f452be4 5fe3ad90 00000000 01ca97c4 00002000 5fe3ae18 5a1bd198 59af60a8
8: 00002000 00000008 01ca97c4 0000207f 24000082 00000000 00000000 00000000
16: 00000000 00000001 59af60a8 5a28b7b0 5fe23680 00002000 01e70000 5ff9fb40
24: 00000000 00000040 5a695668 5fe955b8 00000000 00000040 00000002 00000003
----> 6f452be4 : "MemGuard" segment 0005 offset 8bdc
----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
----> 01ca97c4 : "Kickstart/kernel" segment 0001 offset 497c0
----> 01e70000 : "Kickstart/newlib.library.kmod" segment 0001 offset 061c
LR 014136f0 : "Kickstart/kernel" segment 0000 offset 136ec
CTR 6f452be4 : "MemGuard" segment 0005 offset 8bdc

Stack backtrace:
----> 014136f0 : "Kickstart/kernel" segment 0000 offset 136ec
----> 018c6dfc : "Kickstart/ohci.usbhcd" segment 0000 offset 5558
----> 018c45b4 : "Kickstart/ohci.usbhcd" segment 0000 offset 2d10
----> 018cb608 : "Kickstart/ohci.usbhcd" segment 0000 offset 9d64
----> 018cb788 : "Kickstart/ohci.usbhcd" segment 0000 offset 9ee4
----> 018c90b4 : "Kickstart/ohci.usbhcd" segment 0000 offset 7810
----> 0141587c : "Kickstart/kernel" segment 0000 offset 15878

Disassembly:
014136ec: 4e800421 bctrl
014136f0: 80010084 lwz r0,132(r1)
014136f4: 38210080 addi r1,r1,128
014136f8: 7c0803a6 mtlr r0
014136fc: 4e800020 blr

and after a requester said:

disk Rally2 has an error on block=298992.
error = 20
disk error


And I have seen and reported the same error on AOS4.1 version also(see post #22 before-look like the same), and allways on AOS4.1.1

A reboot and the key is allways recognized fine. great. I wil continue some tests soon.

NOTE 1:

Yes, catched by memguard and no by grim reaper and also sorry for not having the usb.log because as the error = 20 is showed on the requester and I have teied to open ram:=bad idea. next time will be to quit the error requester and try to open the Ram:

NOTE 2:

The USB copy become more and more slower with drawer like AISS / toolbarimages, with 3500+ small images inside. At the end of this drawer copy, a little bytes file take one second or two ???????


Edited by Mrodfr on 2010/1/28 18:23:36
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: usb 16go key copy problem on SAM
Just can't stay away
Just can't stay away


See User information
@Mrodfr

I just copied my whole OS4 installation on a FAT32 formated Kingston 2 GB key. The copy process works fine but when I plug the key on a PC, it says it's broken :-/


Edited by Elwood on 2010/1/30 23:24:03
Philippe 'Elwood' FERRUCCI
Sam460ex 1.10 Ghz
http://elwoodb.free.fr
Go to top
Re: usb 16go key copy problem on SAM and AOS4.1 U1 (now)
Amigans Defender
Amigans Defender


See User information
@Mrodfr

(I put this in another thread but it is more relevant here)

CrossDOSFilesystem was changed for v53, however this may not be entirely relevant as v53.1 on OS4.1 had the problem also.

WINDOWS1252/(V53.2)
        
Convert 8p3 names not with CodePage 858 but with
        Windows
-1252which is more ISO likeNote that this is not
        how Windows actually does it
but it is like
        CrossDOSFileSystem prior to V53.2 did it
.


It can be reverted back with the above switch. Unfortunately there's no way of setting CONTROL options for USB devices to see if this fixes the problem, that I know of.

It would be good if this and the other control options could be set in the CrossDOS commodity, as they could be quite useful regardless.

Go to top
Re: usb 16go key copy problem on SAM and AOS4.1 U1 (now)
Just can't stay away
Just can't stay away


See User information
@Chris
I owned and updated the commercial CrossDOS for OS3 for years and the manual always suggested or warned that disks should be formatted with a real MS PC. With OS4.x I stick to single file copies to a single directory on USB memory sticks. Large copies (dragging a partition to the USB stick) seldom work properly for me with FAT formatted sticks. I formatted my 16GB USB memory sticks with SFS and use them for backup. There seems to be a speed difference depending on the stick size. My first 1GB stick was really fast. They seem to have gotten progressively slower as I bought bigger sizes (2GB, 4GB, 8GB etc.) It seems especially noticeable on the 16GB stick I've got. It seems really slow.

Go to top
Re: usb 16go key copy problem on SAM and AOS4.1 U1 (now)
Quite a regular
Quite a regular


See User information
@Chris

Quote:

CrossDOSFilesystem was changed for v53, however this may not be entirely relevant as v53.1 on OS4.1 had the problem also.

WINDOWS1252/(V53.2)
        
Convert 8p3 names not with CodePage 858 but with
        Windows
-1252which is more ISO likeNote that this is not
        how Windows actually does it
but it is like
        CrossDOSFileSystem prior to V53.2 did it
.




OK. V53.2 convert 8p3 names now with Windows-1252. Great to know that CrossDOS has been improved to try to resolving the FAT32 problem Kicko and I and another user have sometime and thanks for sharing with use this information.

A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: usb 16go key copy problem on SAM and AOS4.1 U1 (now)
Quite a regular
Quite a regular


See User information
@xenic

Quote:

xenic wrote:

I owned and updated the commercial CrossDOS for OS3 for years and the manual always suggested or warned that disks should be formatted with a real MS PC. With OS4.x I stick to single file copies to a single directory on USB memory sticks. Large copies (dragging a partition to the USB stick) seldom work properly for me with FAT formatted sticks. I formatted my 16GB USB memory sticks with SFS and use them for backup. There seems to be a speed difference depending on the stick size. My first 1GB stick was really fast. They seem to have gotten progressively slower as I bought bigger sizes (2GB, 4GB, 8GB etc.) It seems especially noticeable on the 16GB stick I've got. It seems really slow.


All my USB hardware are really factory formated with a PC (untill now).

Quote:

With OS4.x I stick to single file copies to a single directory on USB memory sticks. Large copies (dragging a partition to the USB stick) seldom work properly for me with FAT formatted sticks.


What does that mean ?? you make a drawer on the USB key and copy all inside surely....

About the speed to copy to the 16gb USB key I have is when copy the 3500 small files inside AISS, the last one has been copied with verry verry slow speed (first one with correct speed).

A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: usb 16go key copy problem on SAM and AOS4.1 U1 (now)
Just popping in
Just popping in


See User information
Hyep, I just had a problem copying to my 16GB DataTraveller USB stick.

Before OS4.1 Update 1 I couldn't even copy data from FAT formatted USB sticks. Since 4.1u1 I have copied lots of large files from FAT USB sticks and an external HD without problems.

Tonight was probably the first time I risked writing a file to a FAT filesystem on USB, though. Just a small text file.

This was the contents of the original:

642e3f7597bb3f30b8219f66685023d9  VIDEO_TS/VIDEO_TS.BUP
642e3f7597bb3f30b8219f66685023d9  VIDEO_TS
/VIDEO_TS.IFO
b8763747b93b078d9cd9130923067479  VIDEO_TS
/VIDEO_TS.VOB
03bb4e2747605cdb3f72634d55416566  VIDEO_TS
/VTS_01_0.BUP
03bb4e2747605cdb3f72634d55416566  VIDEO_TS
/VTS_01_0.IFO
b8052fd6f3ba2b69f3a346f2671a370f  VIDEO_TS
/VTS_01_1.VOB
a192d0988b1752ad322137bf2efafa71  VIDEO_TS
/VTS_02_0.BUP
a192d0988b1752ad322137bf2efafa71  VIDEO_TS
/VTS_02_0.IFO
4b0099fc12ed92c733bb0ae3649f19b1  VIDEO_TS
/VTS_02_1.VOB
411a1af1c0cc091e397b185624dcd4e4  VIDEO_TS
/VTS_03_0.BUP
411a1af1c0cc091e397b185624dcd4e4  VIDEO_TS
/VTS_03_0.IFO
0fae12d64a5e157fc0906be50884e5f8  VIDEO_TS
/VTS_03_1.VOB
beff17808ff8a6218bee2808b05233ac  VIDEO_TS
/VTS_04_0.BUP
beff17808ff8a6218bee2808b05233ac  VIDEO_TS
/VTS_04_0.IFO
8d779077557be07e6eb5f0f71c357b10  VIDEO_TS
/VTS_04_1.VOB
cb6618a8073462d59c649a4cb4e68ca3  VIDEO_TS
/VTS_05_0.BUP
cb6618a8073462d59c649a4cb4e68ca3  VIDEO_TS
/VTS_05_0.IFO
d0430aeb13dee621457b481e0544ccec  VIDEO_TS
/VTS_05_1.VOB



And this is the content of what ended up on my USB stick:

642e3f7597bb3f30b8219f66685023d9  VIDEO_TS/VIDEO_TS.BUP
642e3f7597bb3f30b8219f66685023d9  VIDEO_TS
/VIDEO_TS.IFO
b8763747b93b078d642e3f7597bb3f30b8219f66685023d9  VIDEO_TS
/VIDEO_TS.BUP
642e3f7597bb3f30b8219f66685023d9  VIDEO_TS
/VIDEO_TS.IFO
b8763747b93b078d9cd9130923067479  VIDEO_TS
/VIDEO_TS.VOB
03bb4e2747605cdb3f72634d55416566  VIDEO_TS
/VTS_01_0.BUP
03bb4e2747605cdb3f72634d55416566  VIDEO_TS
/VTS_01_0.IFO
b8052fd6f3ba2b69f3a346f2671a370f  VIDEO_TS
/VTS_01_1.VOB
a192d0988b1752ad322137bf2efafa71  VIDEO_TS
/VTS_02_0.BUP
a192d0988b1752ad322137bf2efafa71  VIDEO_TS
/VTS_02_0.IFO
4b0099fc12ed92c733bb0ae3649f19b1  VIDEO_TS
/VTS_02_1.VOB
411a1af1c0cc091e397b185624dcd4e4  VIDEO_TS
/VTS_03_0.BUP
411a1af1c0cc091e397b185624dcd4e4  VIDEO_TS
/VTS_03_0.IFO
0fae12d64a5e157fc0906be50884e5f8  VIDEO_TS
/VTS_03_1.VOB
beff17808ff8a6218bee2808b05233ac  VIDEO_TS
/VTS_04_0.BUP
beff17808ff8a6218bee2808b05233ac  VIDEO_TS
/VTS_04_0.IFO
8d779077557be07e6eb5f0f71c357b10  VIDEO_TS
/VTS_04_1.VOB
cb6618a8073462d59c649a4cb4e68ca3  VIDEO_



I got the "write error" requestor and I tried to RETRY a few times. I had to reboot because Workbench was frozen. I could move windows but I couldn't close any, and only the backdrops would redraw, not the contents.

The file above is what was on the USB stick after I rebooted.

The filename was OK. I haven't checked to see if the md5sums on the rest of the files on the stick are still OK.


I use an SFS-formatted USB stick for backing up Workbench and Work partitions and I haven't had a problem yet. That worked before 4.1u1, too.

Go to top
Re: usb 16go key copy problem on SAM and AOS4.1 U1 (now)
Quite a regular
Quite a regular


See User information
@robo-ant

Hello and welcome to the club

Thanks for your report and another time the error located on 16GB medias.

What mean your before AOS4.1, FAT95 failed allways ??? I don't understand really the before and after AOS4.1U1 explanation.

As you have seen, there are problems with FAT95 medais on USB with AOS4.

- What look like the write error requester ???
- You copied things with a filemanager (dopus4) ???
- The USB reset during the copy (USB mouse and keyboard) ???

A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top
Re: usb 16go key copy problem on SAM and AOS4.1 U1 (now)
Just popping in
Just popping in


See User information
@Mrodfr

Quote:
What mean your before AOS4.1, FAT95 failed allways ??? I don't understand really the before and after AOS4.1U1 explanation.


FAT32 USB volumes used to get read errors for me, with the OS4.1 beta (SAM). It was dangerous to copy files _from_ a USB stick. Now with OS4.1u1 I have successfully copied many, and large, files from USB media, with no errors.

With either version of the OS, it seems dangerous to copy files _to_ a FAT32 USB device.

Note that the small file I copied last night was named simply "files.md5", so no special characters or long filenames were involved.

Quote:

What look like the write error requester ???


Um, a normal system requester, I guess. I didn't pay that much attention to what it looked like, and I couldn't get a grab of it because Workbench was locked-up.

It said there was a write error on some block with a big number that I didn't write down.

Quote:

You copied things with a filemanager (dopus4) ???


Nope. I dragged the file to the volume using Workbench.

Quote:

The USB reset during the copy (USB mouse and keyboard) ???


I don't know if USB reset during the copy. I have a SAM440EP so I have to use USB mouse and keyboard. The mouse was still working after the error. Workbench was locked-up and I didn't have anything I could type into, so I don't know if the keyboard was still working.

Also, I don't have any USB hubs connected, or anything like that. Apart from the mouse and keyboard, the USB stick was the only USB device connected to the SAM.

I use this same USB stick with Windows all the time, and occasionally with Linux, and I haven't experienced a problem with it on those operating systems.

Go to top
Re: usb 16go key copy problem on SAM and AOS4.1 U1 (now)
Just popping in
Just popping in


See User information
@Mrodfr

Darnit! I just tripped over this again by accident!

I had a large directory of stuff on my 16GB DataTraveller USB stick. I copied it to my Sam's HD. I didn't like the name, so I renamed... the wrong one! I accidentally renamed the one on the USB stick.

The result: The direcory disappeared! But the space on the stick was not freed. So it was not deleted, just the directory entry was lost.

Good thing I had a copy.

I copied the rest of what I wanted saved to my Sam, and then reformatted the stick on a WinXP box.

I wish this stick had a write-protect tab that I could set before plugging it into my Sam!

BTW, I have been using a FAT formatted 16MB (yes, megabyte) CompactFlash card to xfer files back to the Windows box, and that has worked so far. Maybe this really is some issue with media size.

Go to top
Re: usb 16go key copy problem on SAM and AOS4.1 U1 (now)
Quite a regular
Quite a regular


See User information
@robo-ant

Hum, interesting. I have also my 16GB USB stick who have caused problems before. I will try to do your test...

BTW, there are differents clusters for FAT32. As ly key is a speedy one, maybe with big clusters... BTW, the crash when renaming your Key isn't related to clusters.

A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT
SAM440EP on Mapower 3000+AOS4.1

Amiga Docs Disk Preservation Project
Go to top

  Register To Post
« 1 (2) 3 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project