SMBFS generates lots of warnings and won't compile (mostly SOLVED)

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.

@dwolfman

main.c:466: warning: pointer targets in passing argument 1 of 'strlcpy' differ in signedness

The string warnings are usually because it supplies an unsigned char * and not a char *, or vica-versa.

This is a missing include, sys/something..

main.c:1428: error: 'fd_set' undeclared (first use in this function)

This because of the above

main.c:1428: error: expected ';' before 'read_fds'

Ths is in the same incude as above

main.c:1498: warning: implicit declaration of function 'FD_ZERO'

Fix the signed/unsigned problems, and include the file and it should compile

Simon

@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.

@dwolfman

#include <sys/select.h> will cure the problem with not finding the fd_set structure.

The signed/unsigned issues will remain, that is down to the difference between static strings and the function prototypes.

Simon

@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.

@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.

@dwolfman

If you need some beta testers for your compile...an upload to OS4depot would be nice...

@cha05e90

I guess that if Olaf did not published its work yet there is a reason so I don't think publicly releasing an unofficial version would be a wise idea. Anyone has access to the sourceforge repository and should be able to compile it if he really want to use a beta version.

@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.

@dwolfman

Why not use GetTimeZoneAttrs() from timezone.library?

@dwolfman

Quote:

Yes go for a call to and you'll receive in currentOffset the current timezone offset from UTC time, i.e. when DST is in effect it will reflect it, if you need to know what is the standard offset (i.e. when DST is *not* in effect) use TZA_UTCOffsetSTD instead and when you need what is the DST offset use TZA_UTCOffsetDST. Finally TZA_TimeFlag might be handful when trying to know if is DST is in effect or not.

PS: there are some ANSI/ISO functions (localtime(), gmtime(), etc.) but at least in Newlib it seems there are some problems with them when DST is in effect.

EDIT: Did you tried to contact Olaf via Sourceforge to see what he will say about this problem ? Maybe he will be able to fixe it ?

@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.

@dwolfman

As you want, I'm a bit surprised you didn't find anything using google about localtime, gmtime etc because they are ISO standard and well documented everywhere, for example google gives me for gmtime this link : http://www.opengroup.org/onlinepubs/0 ... 399/functions/gmtime.html which is pretty good and also describes other time functions. Anyway did you tried to contact Olaf ? He's a nice guy that might help you.

@abalaban

Oh, yeah, I found a lot of stuff like that in Google searches too. Problem is I was looking for Amiga-specific stuff so skipped by a lot of them.

Looks like I'll have to experiment with them and see if they work correctly on my system or not. I was hoping to find Amiga-specific documentation which clarifies exactly what the function IS going to do on an OS 4 system.

@dwolfman

Hmm, I think I'm seeing some of what others mentioned about how the libs work. :-/

clib2 returns -1 for tm_isdst on a locatime call with current time. Newlib returns 1 (which it should since DST is in effect for me right now).

Problem is Olaf has the compile set up to use clib2, so I can't use the built-in functions for this.

I'm going to try compiling smbfs for newlib instead of clib2, without making other changes. If that works, then I can use the built-in functions to get it.

@dwolfman

OK, so much for switching to newlib. Apparently the functions are a little different between newlib an clib2. :-/

Timezone.library it is, then.

Oh, I haven't tried contacting Olaf yet. For right now I'm having too much fun experimenting with this.

Finding out how rusty my C-coding skills are in the process. Kept forgetting to put semicolons at the end of the lines in my test program.

@dwolfman

OK, my coding skills are too rusty right now. Plus I must be missing some includes somewhere because I can't get it to compile. Keeps complaining about ITimezone not being defined when first used, then dropping with "error 1" just like when I didn't have the right includes linked in earlier.

Think I'll find a way to do this in a DOS script and adjust the command line option for ambfs accordingly.