Antique wrote:
Any plans to make support for blu ray disks for os4(reading)?

Paul wrote:
[...] I couldn't delete it, even from a DOS prompt in shell, because ti still showed as having some content (the empty directory.) [...]

and

[...] I finally got rid of the nested, recursive directory problem by formatting the System: partition and then copying back the fresh drag and drop backup I had done. [...]

Amigamancer wrote:
@Cyborg
Quote:

Why does it decrompress everything into RAM first before copying to disk?? That feels like ... well ... wrong..

Yes, IF this is what it does, it's just wrong.

Chris wrote:

[...] it decompresses completely to RAM before dumping to disk.

Quote:

Or is that maybe a XAD limitation? I did never use XAD in coding, so I know as much about it as about 7zip internals .. well, if it is a XAD problem, then XAD could need a revise..

I have used it to decompress big lha and old zip files, and it doesn't do that. I don't know what is the case with 7z files. If it decompress them in RAM first, i'd say it's a fault of the client, not of the XAD system.

However, I suspect even with the maximum 2GB memory (some as swap partition), a 1.6GB file is going to use all that up. Both the compressed file and the decompressed data (plus some overhead) are going to come right up to the 2GB limit - it decompresses completely to RAM before dumping to disk.

olsen wrote:

- It's sometimes useful to reduce the default MTU value if you know that traffic to leave your network will always have to squeeze through a gateway which limits the size of the packets. An example is the PPPoE protocol which is widely used for ADSL services in Europe. PPPoE limits packet size to 1492 bytes payload. If you limit the MTU value in your network clients, it may mean that there will be less friction since converting between the packets that go into the router and have to come out, chopped into smaller units. Chopping up the packets in transit may result in extra traffic since some packets cannot be conveniently broken into smaller units and will have to retransmitted. This "optimization" through MTU limits may, however, accomplish nothing tangible.

- Why such a strange MTU value? For Ethernet the MTU is 1500 (for gigabit ethernet its actually up to 9000, but that isn't supported yet). Thats also true if you access the Internet through a router. Only if you are directly connected to the Internet with your Amiga (e.g. through PPPoE), you might have to worry about the MTU value and set it to something below 1492 for DSL.. but even that would Roadshow do for you with the Wizard..

Curty wrote:
@Curty

Got it working,

case DOCKYGET_Version:
*msgData = DOCKYVERSION;
break;

was causing the problem.

In the old sdk

#define DOCKYVERSION ((uint32)((( 50 )<<16)|( 49 )))

and in the new sdk

#define DOCKYVERSION ((uint32)((( 50 )<<16)|( 50 ))
is how its defined.

I changed the code in my docky to

case DOCKYGET_Version:
*msgData = 52;
break;

and it now works so it looks like this is an sdk problem.

olsen wrote:
@Cyborg

Um, some notes on this:

- It's OK to set DHCP and a static IP address in the configuration. The effect this has is to alter the DHCP exchange on the client's side. Instead of asking the DHCP server to assign an IP address and provide for information on the default gateway and the DNS servers, the client tells the server "this is my IP address, take it or leave it" and picks up whatever the server could provide. Mind you, this is not recommended unless you are certain that you need things to work like that.

- While you are free to choose the IP address range used in your local network up to a point, you should observe certain rules. The 10.*.*.* IP address range corresponds to a network address of 10 and a host address of the remaining 24 bits, which accounts for the netmask of 255.0.0.0. You should not change the netmask to 255.255.255.0 unless you are using the reserved IP address range of 192.168.*.*. Of course, mucking with the netmask works most of the time, but some software will get into hot water if the reserved IP address ranges and their corresponding default network mask values don't match.

- It's sometimes useful to reduce the default MTU value if you know that traffic to leave your network will always have to squeeze through a gateway which limits the size of the packets. An example is the PPPoE protocol which is widely used for ADSL services in Europe. PPPoE limits packet size to 1492 bytes payload. If you limit the MTU value in your network clients, it may mean that there will be less friction since converting between the packets that go into the router and have to come out, chopped into smaller units. Chopping up the packets in transit may result in extra traffic since some packets cannot be conveniently broken into smaller units and will have to retransmitted. This "optimization" through MTU limits may, however, accomplish nothing tangible.

Snuffy wrote:
@tlm

via a DSL...
I've been trying to connect with ATT DSL myself and can't. I think I'm upposed to use the 'ppp-ethernet.device' but I don't think it's compatible to newer DSL modems. The NetInterface doesn't get setup correctly. Like you, help is needed. Glad you started this thread!

Edit:
Anyone using PPPoE via DSL on their A1?

Slayer wrote:
@tlm

okay from devs:

# DEVS:NetInterfaces/PPC440EP_ETH
# File generated by Dialer 52.1 (11.12.2006)
# On Friday, 09-Jan-09 at 06:55:32
device=ppc440ep_eth.device
configure=dhcp
address=10.1.1.5
netmask=255.0.0.0
mtu=1478

The mtu is optional I just added that recently just incase it made a difference, I guess your configure line would = static not dhcp?

I have altered Roadshowcontrol but then again this shouldn't matter for a case of getting you online:

...
tcp.mssdflt = 1478
...

If something doesn't happen for you this time I'll go through the process of setting my link up again with the wizard and note down the steps taken to get online

I get an output thats not in English. Below is just a small text output I get when run.

...
[AppDockClass.c] mNew: Entrato
...

As for the corrupt memory sticks thing, I think whoever mentioned file comments hit the nail on the head. I've been careful to remove file comments or copy through the shell (copy command defaults to not copying comments for some inexplicable reason) since this came up, and haven't had a single problem.

The downloading AWeb and copying across test would seem to confirm this: The AWeb archive is almost certainly going to have a file comment when it is downloaded, but won't have any other oddities (fairly normal name, although goes over 8.3 limit, not particulary large etc)

Chris wrote:
This is a cracking one!

Open a shell and type the following:

rx "address workbench 'window s:shell open'"

-> Displays S:Shell as expected, in "show only icons" view.

Activate the new window and press alt+up

-> Displays the parent, also in "show only icons" view.

Activate the new window, and choose "Show => all files" from the Window menu.

-> Shows all the files... except the Shell drawer.
If you put it in view by name mode, there is a little gap where Shell should be!

Even better - go into SYS: and the S directory has also disappeared!

They won't reappear until you close all the child windows, no matter what you do.

ZeroG wrote:
Do you remember where is was reported?

I can reproduce it with 3 different USB-"disks" on my A1 and my SAM, and i dont have any problems if i use SFS instead of CrossDOS.

It wound be a big step forward if i had to use md5sum to find a error.

I simply have to copy a few files to a fresh formated USB-Disk and the next time i open the root directory most of the filenames have changed to something like ?%(&iidd8, the timestamps and filesizes have changed and it shows directories, but i dont have created/copied a single directory.

I could make a 1:1 image using rawdisk from my 512MB USB-Stick if you want to have a look at it.