g: is the XP system volume. x: is the truecrypted NTFS partition. No problem to set / get / show file attributes with Win32 GUI on both volumes. Same with attrib.exe on console.

sysutils.FileGetAttr(g:\*) is fine, as well, but FileGetAttr(x:\*) returns -1 as an error.

After copying a file from x: to g:, its attributes are - surprise - ok again. Even bigger surprise: After re-copying from g: to x:, FileGetAttr(x:\...) delivers the same correct result as on g:

Any idea?

Wolfram

FileGetAttr is not supposed to accept wildcards.

Michael.

Sorry. Just looks like wildcards here in my post. Of course, FileGetAttr('*') doesn't be exact with my issue, assume a specific file x:\any.any, where x: is a mounted, truecrypted NTFS volume.

FileGetAttr('x:\any.any') returns -1, i.e. error.

After copying x:\any.any to g:\any.any, FileGetAttr('g:\any.any') returns 32, i.e. faArchive.

After copying g:\any.any back to x:\any.any, overwriting the previous version, FileGetAttr('x:\any.any') now returns 32, i.e. faArchive as well, as it should have been always, since we never modified the attributes.

Trying the same on XP GUI or with attrib.exe on console, I don't see any similar issues.

Wolfram

Well,

This is the implementation of FileGetAttr:

Function FileGetAttr (Const FileName : String) : Longint;
begin
   Result:=GetFileAttributes(PChar(FileName));
end;

As you can see, the function returns the result of the GetFileAttributes Win32 API call. Why this call returns -1 is something that we cannot speculate on. Most likely seems an error in the filesystem driver.

Michael.

Thanks, Michael. Came to the same result.

Obscure enough, I have no problems using TSearchRec attributes via FindFirst / FindNext. Maybe I still need some additional, lonesome research and the issue is sitting in front of my monitors.

Wolfram

You can try calling getlastoserror to see whether it gives a more informative reason for the failure.

Jonas