@kas1e

Think something like diskimage.device but for archive files instead of disk images...

@kas1e

xad can't pack nor edit archives.

Also, since there's xadfs for MorphOS (since 2.0), I can tell you it's nice to have this kind of filesystem and use it to browse archives transparently, *but* it easily shows its limits performance-wise, with big files (even with some sort of caching).

@Fab
In others words : xad suck ?:)
Btw, that xadfs are used in Ambient for archives already ?

@Salas00
Then i understand it more or less right. We can press by mouse in Filer (for example) on archive, and it will give us the partition on which we have files, and which we can change/erase/add/etc ?
I see that we can add some easy script, which will jump at the created partition after we will press on archive. Maybe some mockup in end still will need for Filer in that terms, but imho its pretty nice already.

Last edited by kas1e on 03-Sep-2010 at 04:36 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Yes, it's used for that kind of thing.
And it's not that it sucks, but using it as a handler (let's say for Read() operation) is slightly problematic, since you can't extract only a part of a file, but the whole file until you reach the desired offset.

If there's no caching at all, each Read() operation will trigger an xad extraction of the entry until (readpos + size), which as you can imagine isn't optimal.

So for example, if your enduser application requests reading the end of the file (for mimetype recognition, for instance... it can happen in some cases), the handler will have to extract all of it, and if it's a big RAR file, it takes its time. :)

@Fab

Uhm .. That is suck then. For example for 500mb archive, for just checking readme file in the main directory, you will need to wait while the whole archive will be extracted to memory ..

Interesting then, how its done any other os, like for example winxp+total commander. I can go in any archive and does not matter how big is it, and its not take years. Some kind of cash ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

No, that's on a per-file basis. Extracting a small readme from a big archive won't take long at all, fortunately.

And about your comparisons to other os/programs.. It's easy to make it faster when it's not a real DOS handler. See for instance xadopus.

@kas1e

I now have file i/o working with most programs except for multiview amigaguide datatype which for some unknown reason insists on seeking 41554 bytes into a 41553 byte file , which of course fails and then it complains about "Not enough data". This doesn't happen if I copy the file from XAD0: to RAM: and then open it from there though.

Also WB refuses to open any directories apart from root dir .

@salass00

That very cool !

So, in general we will can also browse archive even in WB ? (without using of Unarc and alt).

Btw, what you think about last Fab's replyes ? (i mean how fast for example will be mounts the 500mb file) ? By diskimage.device, all my isos mounts in 1 sec. As i understand its for now "real dos-handler" ? (will have some limitation, not like xadopus) ?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Fixed the WB problem. Turned out the correct return values for ACTION_SAME_LOCK are DOSTRUE/DOSFALSE, not LOCK_SAME/LOCK_DIFFERENT.

@kas1e

The problem is not to mount them... It's almost instant. It becomes an issue when actually reading from a big entry *inside* the archive.

@salass00

cool project!

_________________
AOS4 Betatester, Peg2, G4@1ghz, Radeon 9250 256mb, 1gb RAM.

http://www.asciiarena.com
http://www.uprough.net

@spotUP

Software that you use on a regular basis is worth paying for... assuming the price is not too exorbitant and that the software is stable. Even better if it offers some enhancements over the existing software. At the very least choice is a good idea.

@salass00

Quote:

Fixed the WB problem. Turned out the correct return values for ACTION_SAME_LOCK are DOSTRUE/DOSFALSE, not LOCK_SAME/LOCK_DIFFERENT.

Turns out this also fixed the AmigaGuide problem.

@Fab
Quote:

The problem is not to mount them... It's almost instant. It becomes an issue when actually reading from a big entry *inside* the archive.

Just want to understand, will Salas00's work have the same problem or not (as i understand it will, because its the same as xadfs on morphos ?)

@Salas00
Awesome! Can we try it already ?:) Want to add that to Filer (because i use dopus all the time when works with archive).

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

I've started a new thread here. I think it's best if we use it for further discussion on XADFS.

@Fab

I wasn't aware that there was a similar filesystem already for MOS. This is an idea that I've had for years but only recently I've started working on it more seriously.

@kas1e

Currently the filesystem just unarcs each file to a temp directory as it's accessed (this works fine for small files at least). I'll replace it with a more advanced method once I have some more of the basics working.

@olsen

Quote:

I hope to get DHCP client reliability improved, but for that to work out I first need to understand better what exactly it is that causes trouble.

About that. Below is an excerp from my Amiga meeting I wrote about that we were looking at:

* OS4's Roashow issue. The OS4 internet stack can have an issue
getting an IP address from DHCP. Jeff has been debugging this with
ethernet debuggers. Sometimes a DHCP server can send back a unicast
address when it should be sending a broadcast address. Hence, no IP
address! Roadshow is not equipped to deal with this apparently.
Linksys routers can do this. It's possible DLink can as well if used
though a wireless adapter.

@olsen

Quote:

Writing an Amiga file system is the most difficult challenge the operating system has to offer

Of course writing a handler is an easier job.

I wrote a simple one once, called VOID, that worked like a blackhole. Everything copied into it just disappeared. Hehe.

Might make a good practical joke.

But I made that easier on myself. I made use of two tools. And I wrote it in AmigaE. Which also made it easier for me. The tools were the E source code debugger. And another I wrote myself, called TestHandler, which allowed you to mount a DOS device and attach it to a task.

I thought TestHandler was quite good for the simple thing it did. It allowed you to debug a handler in real time using any programming language and debugger you liked! I was quite proud of the fact that I was told this was something you cannot do. But I was disappointed at the "non-critical" acclaim I got. IIRC, not even a single email saying how bad or good it was. As a programmer the worse you can get is the silent treatment.

It worked simply by creating a startup packet and sent it to your task, waited for the reply and mounted a device. Done! Oh no my big secret is out.

I mainly used DOpus for testing but could see the strange things it does. It was really useful to see what packets I was getting. One of those lttle gems I thought.

Now if only OldFart had access to a source code debugger I could make his life slightly easier with that handler debugging...

@Hypex

Quote:

Hypex wrote: @olsen Quote: I hope to get DHCP client reliability improved, but for that to work out I first need to understand better what exactly it is that causes trouble. About that. Below is an excerp from my Amiga meeting I wrote about that we were looking at: * OS4's Roashow issue. The OS4 internet stack can have an issue getting an IP address from DHCP. Jeff has been debugging this with ethernet debuggers. Sometimes a DHCP server can send back a unicast address when it should be sending a broadcast address. Hence, no IP address! Roadshow is not equipped to deal with this apparently. Linksys routers can do this. It's possible DLink can as well if used though a wireless adapter.

Thank you, that confirms what I discovered just today by looking at a tcpdump capture kindly provided to me.

The problem is that the DHCP offer sent by the server in response to the DHCP client's discovery request is not supposed to come out as a unicast message.

I don't know if you took packet samples, but the case I saw actually had the server send its response to a specific IP address, which hadn't even been assigned. This looks like a misinterpretation of the rules for DHCP servers in a LAN, which have to broadcast the message. Unicast is permitted only, if memory serves, for DHCP relay operations, and then only between relays. The DHCP client is not supposed to see anything but the broadcast traffic.

The pieces of the puzzle aren't all in yet, but I suspect that fixing the issue in Roadshow might just mean introducing a bug into Roadshow's code. That sucks

Last edited by olsen on 04-Sep-2010 at 07:32 PM.
Last edited by olsen on 04-Sep-2010 at 07:30 PM.

@Hypex

Quote:

Hypex wrote: @olsen Quote: Writing an Amiga file system is the most difficult challenge the operating system has to offer Of course writing a handler is an easier job.

That depends. There are varying grades of difficulties even in writing a handler

Quote:

I wrote a simple one once, called VOID, that worked like a blackhole. Everything copied into it just disappeared. Hehe. Might make a good practical joke.

Or a particularly fancy replacement for the NIL: device

Quote:

But I made that easier on myself. I made use of two tools. And I wrote it in AmigaE. Which also made it easier for me. The tools were the E source code debugger. And another I wrote myself, called TestHandler, which allowed you to mount a DOS device and attach it to a task. I thought TestHandler was quite good for the simple thing it did. It allowed you to debug a handler in real time using any programming language and debugger you liked! I was quite proud of the fact that I was told this was something you cannot do. But I was disappointed at the "non-critical" acclaim I got. IIRC, not even a single email saying how bad or good it was. As a programmer the worse you can get is the silent treatment. It worked simply by creating a startup packet and sent it to your task, waited for the reply and mounted a device. Done! Oh no my big secret is out. I mainly used DOpus for testing but could see the strange things it does. It was really useful to see what packets I was getting. One of those lttle gems I thought.

A tool for that purpose has been around for quite a while. I don't remember exactly what it was called, but it was published ages ago on a Fred Fish disk.

@olsen

From RFC 2131:

Quote:

In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured. To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents.

So, either the client should accept the packet, or the server must honor the broadcast flag....

EDIT: Oops. RFC 2131, not RFC 2121.

Last edited by Trev on 04-Sep-2010 at 09:25 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603