ExpandUNCFileName not working as expected?

[Hansaplast]

The ExpandUNCFileName function (in sysutils) on a Mac returns the mount point instead of the actual share location.

According to the manual:

ExpandUNCFileName runs ExpandFileName on FileName and then attempts to replace the driveletter by the name of a shared disk.

Now I assume this was written with Windows in mind (driveletter), and maybe I wrongfully assumed this would mean that the full UNC to the actual share would be returned.

For example a mount point:

Code: [Select]

/Volumes/Projects
could point to the Projects share on MyServer, and it's actual UNC should be

Code: [Select]

//MyServer/Projects
ExpandUNCFileName('/Volumes/Projects') however returns /Volumes/Projects ...

Is this a bug?
Does anyone know how to retrieve the correct UNC?

[Jonas Maebe]

//MyServer/Project has no special meaning on Unix, it has the same meaning as (the path) /MyServer/Project. UNC is a Windows concept and ExpandUNCFileName can/will indeed only replace drive letters. There is no way to get an UNC path on Unix, nor any implementation for walking over all mount points on Unix platforms (which would probably have to be implemented differently on every supported platform, there is no generic Unix interface for this).

Additionally, that still wouldn't tell you with which protocol that mount point was mounted, and it could be anything from NFS to Samba to a custom-implemented file system that mounts local tar files as a separate file system. I therefore can't think of any possible use for an UNC path on Unix.

[Hansaplast]

Thanks Jonas for the reply.
And what you're saying makes perfect sense.

The reason why I was looking is because I'm trying to maintain a file list in a database and I'd like to be able to "recognize" if I'm adding the same file again, even if the path seems different.
For example on my NAS I have SMB and AFP enabled, which means that a share on my NAS can be mounted 2 ways at the same time, yet pointing to exactly the same file.

Under Windows not a problem, because Windows will not work with AFP anyway and ExpandUNCFileName will make a UNC out of it just fine, even if mapped to more than 1 drive letter

I'm trying to resolve this somehow for Mac (and Linux) as well.
Suggestions and ideas are most welcome ...

p.s. the files are rather large (GB's), so comparing them byte-by-byte is not really an option.

[Jonas Maebe]

Having just the server name would not be safe in that case, because it's possible to share different subdirectories with the different protocols. So implementing support for something like that in the RTL would not be a good idea, since it would not provide any kind of dependable information. I don't think you can do what you want, other than manually configuring your application with the information about which directories alias.

[Hansaplast]

I am afraid that you're right ... 

Implementation in RTL indeed makes limit or no sense.
And finding a way to determine the actual location seems near to impossible (I've tried quite a few options).

Thanks for you input though ...

[Dr.Theopolis]

In case anyone needs an answer to the original question...

with Unix in your uses clause, call statfs

for example

var
  fs: tstatefs;
  s: string;
begin
  s := '/volumes/shared/somefolder/somefile';
  statfs(s, fs);
end

if /volumes/shared is the mount point for, for example, smb://someserver/blah/blah,
then
fs.fstypename would be smbfs
fs.mountpoint would be /volumes/shared
and
fs.mntfromname would be //username@someserver/blah/blah

[Hansaplast]

Thanks Dr.Theopolis!
That's useful info, this would help me "reconstruct" what the UNC is supposed to be (specially the "fs.mntfromname" part).
Thanks again!