Hi all,
I have some problem with a file archiver which uses the Dos unit under Windows, I suspect the flaw resides in GetFAttr function. Looking in the source for Win RTL

procedure getfattr(var f;var attr : word);
var
   l : longint;
   s : RawByteString;
begin
  doserror:=0;
  s:=ToSingleByteFileSystemEncodedFileName(filerec(f).name);
  l:=GetFileAttributes(pchar(s));
  if l=longint($ffffffff) then
   begin
     doserror:=getlasterror;
     attr:=0;
   end
  else
   attr:=l and $ffff;
end;

I noted that two bytes are reported as a result, thought IIRC in DOS only the low byte is affected while the high one should be zero, so the assignment would become

   attr:=l and $ff;

Waiting for your comments,
Marco

Op 2019-01-30 om 14:18 schreef Marco Borsari via fpc-pascal:

Windows attributes can be > 8-bits, see e.g.
https://docs.microsoft.com/nl-nl/windows/desktop/FileIO/file-attribute-constants.

https://www.freepascal.org/docs-html/rtl/dos/getfattr.html however says that they _can_ be examined for a list of attributes, not that others might not be in it. The example code also only tests for attributes, and never does something with all bits.

Windows attributes can be > 8-bits, see e.g. https://docs.microsoft.com/nl-nl/windows/desktop/FileIO/file-attribute-constants.

But the Dos unit is in Windows for compatibility, if one need the extended attributes there is the equivalent function in SysUtils.

https://www.freepascal.org/docs-html/rtl/dos/getfattr.html however says that they _can_ be examined for a list of attributes, not that others might not be in it. The example code also only tests for attributes, and never does something with all bits.

The FAT FS is freezed since long time and I think it is supposed GetFAttr behaves in standard manner.
Anyway it is easy to remedy the problem directly in my source, thank you for your assistance,
Marco