FPC 3.3.1-r43118 [2019/10/04], on Linux x64, cross compiling to FreeBSD x64 12.0 (TrueOS).
Smth is broken in DirectoryExistsUTF8() on FreeBSD. After this FPC update CudaText cannot see that folder (in subdir of home dir, access rights ok) exists. After removing this check in app, app now cannot see that another dir (also in home dir) exists.

I removed VM with freebsd so cannot check in small demo.

 FPC 3.3.1-r43118 [2019/10/04], on Linux x64, cross compiling to FreeBSD x64 12.0 (TrueOS). Smth is broken in DirectoryExistsUTF8() on FreeBSD.

Does SysUtils.DirectoryExists work?

Mattias

Hi Alexey,

If I can have a random guess, it's probably the stat structure being outdated with the C equivalent, therefore whatever tests are being made on the result of fstat() or fpstat() call, is not working properly. The BSDs were notorius for changing their stat structures, or changing the type of some fields in the structure (which totally changes the alignment), maybe even several times during the past years... Decades... :P I had to adapt the NetBSD one too to make it work on recent NetBSD versions a while back, when I brought the NetBSD port to be somewhat up to date.

The structure in question is in rtl/bsd/ostypes.inc.

Sadly I know very little about FreeBSD, and I don't have it in any form, and never had it, so I'd pass on attempting to reproduce and fix this.

Charlie

Does SysUtils.DirectoryExists work?

No, the dir name is pure English, so DirectoryExistsUTF8 does the same.

Alexey Tor. wrote

>Does SysUtils.DirectoryExists work? No, the dir name is pure English, so DirectoryExistsUTF8 does the same.

:-) There is no such thing as "pure English".

I assume what you were trying to say, is that some text are encoded differently, depending on the platform. So you might need to convert the text to the OS Encoding.

eg: fpGUI uses the following, which all fpGUI based applications use, no matter what platform they are on.

function fpgDirectoryExists(const ADirectory: TfpgString): Boolean;
begin
  Result := DirectoryExists(fpgToOSEncoding(ADirectory));
end;

Then the fpgToOSEncoding() has different implementations for various platforms (eg: Unix vs Windows)

// Unix (FreeBSD, Linux etc) - basically do nothing because those OSes
// use UTF-8 by default.
function fpgToOSEncoding(aString: TfpgString): string;
begin
  Result := aString;
end;
// Under Windows I have this implementation
function fpgToOSEncoding(aString: TfpgString): string;
begin
  Result := Utf8ToAnsi(aString);
end;

But as I mentioned, any application developer that uses fpGUI simply needs to use the fpgDirectoryExists() method and doesn't need to worry about encoding/decoding text.

Regards,
Graeme

He meant ASCII.

The encoding is not the problem here.

If this is SysUtils.DirectoryExists, then fpgui suffer from the same bug.
We need someone with FreeBSD x86 12.0 knowledge.

[...]

Mattias

Mattias Gaertner wrote

> :-) There is no such thing as "pure English". He meant ASCII.

No problem. The smiley face also as a hidden meaning. English is such a convoluted language (due to its long history), not even the English (England) can speak it correctly. ;-)

If this is SysUtils.DirectoryExists, then fpgui suffer from the same bug.

Do you have a mailing list archive link where the topic originated from. In my email client the first message of this thread starts with a quoted line, so I don't have much context. I run FreeBSD 10, 11 and 12 and unsure of the bug being referred to. I'll happily investigate further.

Regards,
Graeme

Karoly Balogh wrote

The structure in question is in rtl/bsd/ostypes.inc. Sadly I know very little about FreeBSD, and I don't have it in any form, and never had it, so I'd pass on attempting to reproduce and fix this.

I'll update my FPC 3.3.x and take a look at this later today.

Regards,
Graeme

Graeme Geldenhuys wrote

Do you have a mailing list archive link where the topic originated from.

No worries, I found it.

Regards,
Graeme