@abalaban & salass00

Yeah, I had thought of that, but I had also thought of the clib2/newlib functions you also mentioned (localtime, gmtime, etc). I'd prefer to make as few changes as possible, which could easily be done by using functions from libraries that SMBFS already has access to (like clib2/newlib, dos.library, etc). Less chance for new bugs that way.

So, are there actually any docs out there for clib2/newlib on OS4? I can't find anything in the SDK, amongst the AutoDocs or any other drawers for that matter. Google, Aminet and OS4 Depot searches don't get anything either.

I have some old information that is mostly usable from my old SAS/C 6.5x install. It's clib info at least gives me some basics for how to use the functions, but those are of course for OS 3.x and don't tell me the OS 4.x specifics.

@abalaban

I agree, and I was hoping that Olaf would post here soon to let us know what the status is.

Meanwhile, anyone wanting to compile this from the CVS source would have to make some changes to get it to compile with the OS 4.1 SDK. I'll post that here once I go back through it and make sure of what I had to do. IIRC, I only had to change two files, adding one line to one file and taking out one of the include options in the makefile.

Meanwhile, I'm trying to figure out another fix for SMBFS that is a very annoying problem it's had for years (but it's by design). It's datestamp functions when READING files do not take in to account DST offsets unless you add an option to the command line to tell it what the offset is. It's because AmigaOS (prior to OS4) did not keep track of DST on it's own. OS4 does, so it just needs some code added to see if it's being compiled for OS4 and include some functions to read the current DST/timezone settings and adjust accordingly. Problem is I'm not sure how to go about reading the DST offset in a simple way. There's the TZ environment variable, but it's probably going to be more work than it's worth to build a function that can read it and parse it (variable length timezone abbreviations and offsets). I'm looking through the autodocs to see if there is a simple function I can call which can just tell me if DST is in effect and what the offset is. SMBFS already gets the main timezone offset (without DST) from Locale.library, but I'm not seeing a function in it to read the DST setting. Timezone.library looks like it can, but I'd have to add a whole lot of extra stuff in to SMBFS to open that library since it's not already being opened up by it.

Anyone know if there is a clib2/newlib function I can use to help make this easier? Even if it just makes parsing the TZ variable easier would help.

For right now I'm using the command line option, so at least all my timestamps are right. This really plays havok with the old mirrorcopy program from Aminet (which I still use) when it's doing file comparisons to see what needs to be copied. Since all the timestamps will be off by one hours, it thinks it needs to copy EVERYTHING. This turns in to about 2 GB of data copied from my A1 to my server, every time my backup scripts run, when it really only needs to copy about 10 MB.

@thread

And it works fine, so far.

Just copied about 5 GB of data back and forth through the SMBFS drive with my backup script. Archives after copying tested fine, so no data corruption.

And several of those were LARGE files, like multi-megabyte archives and ISOs and such.

I don't know why Olaf hasn't released this yet. It's been about 5 weeks since he uploaded this large-file patch to SourceForge. So far it looks like it's working fine for me.

@Rigo

Well, looks like getting the "#include <sys/select.h>" in there was all it needed. It just compiled.

And I only needed to change one file. I added the include statement in the file "system-headers.h", which seemed to take care of it for the whole deal.

Still got all those warnings, but at least they didn't stop the compile. Now I need to test it, see if it works or not (this is "bleeding edge" code, right out of the Amiga-SMBFS CVS repo, you know).

Thanks for the help! I'll post again with results of testing.

@Rigo

OK, but the main problem still remains. What file am I supposed to include?

That's why I pointed back to the original make file and included my modified one here. I don't know what the equivalent path in the OS 4.1 SDK would be for the paths I removed. I think Olaf wrote this originally to be compiled with a cross-compiler, hence the unix-like paths on the includes.

I think if the includes can be fixed, the warnings and errors will go away. I just don't know what files/paths it's looking for.

So I thought I'd try out the AmigaOS 4.1 SDK and compile up something that I could really use, the current CVS source of SMBFS to get the ability to write files larger than 16K to my Linux server. Problem is I can't get it to compile.

First off, I had to modify the list of Includes in GNUMakefile.OS4. It included some directory paths (like /usr/...) that don't exist under AmigaOS. Problem is I'm not sure what path should replace those so it finds the equivalent includes in the SDK.

As it is that at least stops it from producing an error and bombing out immediately. It at least now throws out a bunch of warnings before it gives up.

Here's a snip of what I'm getting now:

It continues for quite a bit after that, a lot more of the same kinds of warnings and errors for more functions in main.c.

I'm guessing it either needs some different compiler options or maybe some include files somewhere?

The original GNUMakefile.os4 is here:
http://amiga-smbfs.cvs.sourceforge.ne ... ?revision=1.6&view=markup

This is what it looks like now on my machine, after my changes so far:


Any help would be greatly appreciated.

@Samurai_Crow

This thread got me started at looking in to using Python, but I'm having some trouble getting the necessary documentation.

The "Amiga Python.pdf" document that came with OS 4.1 references some examples in the "Python SDK", but I'm not sure what or where that is. I know the Amiga OS 4.1 SDK doesn't have any examples for Python, at least none that I can find.

I'll be looking through the stuff on Python from the net, but would like to know where to find this referenced documentation for the Amiga version.

@Raziel

Do you know if that G4 is a 7455 like mine? Curious because you can get a higher multiplier then I can. Even at 133 MHz buss speed, I can't go much higher than 1.06 GHz without the multiplier acting like it's been cut in half.

@Raziel

Quote:
That's the reason why I quit trying to run it that way. I couldn't get my speed back up to 933 or 1000 with the buss set to 100 MHz.

What processor do you have?

I've got a G4, the 933 MHz rated 7455 chip. As soon as I try to go past the 8x multiplier, it acts like I've cut the multiplier in half!

I would love to put both my 512 MB modules in, but I'm not giving up my speed for it. I don't care if the buss speed is 100 or 133, but I don't like losing over 200 MHz on the core speed.

@dwolfman

Never mind, got an answer over on AmigaWorld.

Info here:
http://amigaworld.net/modules/newbb/v ... _id=29428&forum=32#506082

@cha05e90

You are right, it's trying to make links from the SDK directory to the system SOs in SOBJS:. Thing is it has an If statement that is supposed to skip the makelink commands if the main cairo lib file is not there. One of the errors has to do with that If statement.

As it turns out, it works fine with OS 4.1. About an hour after I posted the previous message, I got my copy in the mail. It's installed and working beautifully. Plus the SDK installer went through without errors at all, as well as no hang after the reboot.

In any case, something isn't right with how it installs under OS 4.0 (including the July 07 update). I think those install errors have a lot to do with the way it acts after the reboot.

Originally asked this on AmigaWorld, but found out I probably should have asked it here instead.

Anyway, does OWB support using a proxy, preferably through a proxy.pac-style script file?

@thread

Just to make sure of some things, I unpacked every lha archive in the SDK installer and compared the files. I don't see any .so files for the Cairo part anywhere in the unpacked files, comparing it against the package.xml file's contents. Maybe some files were accidentally left out of the archives?

@thread

OK, after another install, it does the same thing. Hangs at the assign command, and only three of the new .so files are the same as listed above.

But, I did make note of where the errors happened during the install. It's just at the end of the Cairo files section, and shows the following errors in a shell window that pops up:

IF: Missing ELSE or ENDIF
MAKELINK: object not found
MAKELINK: object not found
MAKELINK: object not found
MAKELINK: object not found

@xenic

Ah, this reminded me of something!

When I ran the SDK installer, there were some messages that popped up about something that was missing and some links (looked like an error from MakeLink?).

I'm just going to re-run the installer after I wipe out the SDK install I have and see what it does this time.

@ZeroG

Hmm, only libstdc++.so, libssp.so, and libgcc.so match your checksums. The other two do not. I'll unpack the SDK installer again and check those files.

@Rogue

It stops on the SDK: assign command. At least, that's the last line it shows. I suspect it's the execute line that's the problem.

I'm writing this in OWB, after removing the echo and SDK startup lines. I then re-ran the separate script with just the four lines from my original post, and it did not hang.

That's just odd. Running those four commands in User-Startup causes a hang, while running them separately after OS4 is finished booting does not result in a hang.

OK, this is a strange one so figured I'd post it here since I know the Friedens read here more often anyway.

After I installed the new SDK, 53.15 for OS 4.1, on my OS 4.0 system, I rebooted to let the User-Startup changes take effect. However, it never finishes booting. I can see that it got an IP address from my router, and it did continue after that, but then it just stops dead and not even the Ctrl-Alt-Alt keypress will work any more.

Booted with no startup sequence and was able to fiddle around with User-Startup. Found out that it boots fine without the four lines the SDK installer added to User-Startup.

I saved those off in another file in S:, then tried running them after the system was up and booted properly. No hangs. I'm like "WTF!!?!?!?!"

Here are the lines that I moved out of USer-Startup into it's own file (I've named SDK-Start for now):

;BEGIN AmigaOS 4.1 SDK
assign SDK: Work:SDK
execute SDK:S/sdk-startup
;END AmigaOS 4.1 SDK

This really isn't making any sense to me. Anyone else have any idea why those lines make it hang if they are in User-Startup but not hang when they aren't in there?

@joerg

Looks like it might be that, as no matter what I do with the drive, I get -3 for Error, and that is even with properly ISO9660 formatted CD or DVD disks in the drive.

I'll check with Toni Wilen, see if he has any plans to make that work correctly in WinUAE.

@joerg

Hmm, this is strange.

I ran the NSDQuery tool from NSDPatch43_20.lha on Aminet. Here's the output it gave for uaehf.device (used for hard drives and image files) and uaescsi.device (used for other stuff, like CD/DVD ROM/burner drives).


OpenDevice("uaescsi.device", 0, ior, 0x00000000) was successful (Version 1.0)
io_Device: 0x100002AC, io_Unit: 0x00000000
Device supports New Style Device commands.
Device is a trackdisk like device with subtype 0.

Supported commands:
$4000 = #16384 NSCMD_DEVICEQUERY
$0001 = #00001 CMD_RESET
$0002 = #00002 CMD_READ
$0003 = #00003 CMD_WRITE
$0004 = #00004 CMD_UPDATE
$0005 = #00005 CMD_CLEAR
$0007 = #00007 CMD_START
$0006 = #00006 CMD_STOP
$0008 = #00008 CMD_FLUSH
$0009 = #00009 TD_MOTOR
$000A = #00010 TD_SEEK
$000B = #00011 TD_FORMAT
$000C = #00012 TD_REMOVE
$000D = #00013 TD_CHANGENUM
$000E = #00014 TD_CHANGESTATE
$000F = #00015 TD_PROTSTATUS
$0012 = #00018 TD_GETDRIVETYPE
$0016 = #00022 TD_GETGEOMETRY
$0014 = #00020 TD_ADDCHANGEINT
$0015 = #00021 TD_REMCHANGEINT
$001C = #00028 HD_SCSICMD
$C000 = #49152 NSCMD_TD_READ64
$C001 = #49153 NSCMD_TD_WRITE64
$C002 = #49154 NSCMD_TD_SEEK64
$C003 = #49155 NSCMD_TD_FORMAT64



OpenDevice("uaehf.device", 0, ior, 0x00000000) was successful (Version 1.0)
io_Device: 0x1000CEEC, io_Unit: 0x00000000
Device supports New Style Device commands.
Device is a trackdisk like device with subtype 0.

Supported commands:
$4000 = #16384 NSCMD_DEVICEQUERY
$0001 = #00001 CMD_RESET
$0002 = #00002 CMD_READ
$0003 = #00003 CMD_WRITE
$0004 = #00004 CMD_UPDATE
$0005 = #00005 CMD_CLEAR
$0007 = #00007 CMD_START
$0006 = #00006 CMD_STOP
$0008 = #00008 CMD_FLUSH
$0009 = #00009 TD_MOTOR
$000A = #00010 TD_SEEK
$000B = #00011 TD_FORMAT
$000C = #00012 TD_REMOVE
$000D = #00013 TD_CHANGENUM
$000E = #00014 TD_CHANGESTATE
$000F = #00015 TD_PROTSTATUS
$0012 = #00018 TD_GETDRIVETYPE
$0016 = #00022 TD_GETGEOMETRY
$0014 = #00020 TD_ADDCHANGEINT
$0015 = #00021 TD_REMCHANGEINT
$001C = #00028 HD_SCSICMD
$C000 = #49152 NSCMD_TD_READ64
$C001 = #49153 NSCMD_TD_WRITE64
$C002 = #49154 NSCMD_TD_SEEK64
$C003 = #49155 NSCMD_TD_FORMAT64



As you can see, both support 64-bit NSD and TD_GETGEOMETRY commands, so something else is keeping it from reading the disk.