The low level file functions (fexists, fattr, directory,...) do not work 
when the target file is located in a symbolic link folder. For example, the 
following returns an empty array even though 'myfile.*' exists in the 
symbolic link folder 'test':

directory("c:\test\myfile.*")

Is there a workaround for this? I need to determine if a file exists within 
a symbolic link folder.

Best regards,
Boris Borzic

http://xb2.net
http://sqlexpress.net
industrial strength Xbase++ development tools

Boris,

>The low level file functions (fexists, fattr, directory,...) do not work 
>when the target file is located in a symbolic link folder.

All three mentioned functions work fine for me (tested on Windows 7), so it 
might be an access rights issue or something as simple as a misspelled path?

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
       Andreas.Gehrs-Pahl@InterAct911.com
       Andreas.Gehrs-Pahl@EJusticeSolutions.com
       Andreas@DDPSoftware.com
web:   http://www.Aerospace-History.net

Andreas Gehrs-Pahl wrote in
news:1w26l5vmkgqex.1kq61l42v3kow.dlg@40tude.net: 

>>The low level file functions (fexists, fattr, directory,...) do not
>>work when the target file is located in a symbolic link folder.
> 
> All three mentioned functions work fine for me (tested on Windows 7),
> so it might be an access rights issue or something as simple as a
> misspelled path? 

Thanks for the info Andreas.

I double checked this and found that it works from a desktop application 
but not when run as a service. It does not appear to be a permissions issue 
since I have given the service admin privileges. The symbolic link is 
actually pointing to a folder on a network mapped drive. Don't really know 
why it does not work for the service.

Best regards,
Boris Borzic

http://xb2.net
http://sqlexpress.net
industrial strength Xbase++ development tools

Boris,
sounds like the drive is not mapped as long as no user is logged in!
Better not map the drive but use UNC-names instead:
directory("\\fileservername.domain.orglevel\sharename\test\myfile.*")

Regards,
Martin


Am 28.10.2013 03:17, schrieb Boris Borzic:
> Andreas Gehrs-Pahl wrote in
> news:1w26l5vmkgqex.1kq61l42v3kow.dlg@40tude.net: 
> 
>>> The low level file functions (fexists, fattr, directory,...) do not
>>> work when the target file is located in a symbolic link folder.
>>
>> All three mentioned functions work fine for me (tested on Windows 7),
>> so it might be an access rights issue or something as simple as a
>> misspelled path? 
> 
> Thanks for the info Andreas.
> 
> I double checked this and found that it works from a desktop application 
> but not when run as a service. It does not appear to be a permissions issue 
> since I have given the service admin privileges. The symbolic link is 
> actually pointing to a folder on a network mapped drive. Don't really know 
> why it does not work for the service.
> 
>

Martin Altmann wrote in news:479595c5$45a32a15$20fc9@news.alaska-
software.com:

> sounds like the drive is not mapped as long as no user is logged in!
> Better not map the drive but use UNC-names instead:
> directory("\\fileservername.domain.orglevel\sharename\test\myfile.*")

Well the drive is mapped, since I was testing it while I was logged in on 
the desktop. I also tried the UNC name, but it did not work. I think the 
problem may afterall be permissions since the target folder has different 
credentials. 

Thanks for all your help. BTW, I don't think you can get this quality of 
detailed technical help if you were using a mainstream development tool.

Best regards,
Boris Borzic

http://xb2.net
http://sqlexpress.net
industrial strength Xbase++ development tools

Boris Borzic wrote:

> Well the drive is mapped, since I was testing it while I was logged in on 
> the desktop. I also tried the UNC name, but it did not work. I think the 
> problem may afterall be permissions since the target folder has different 
> credentials. 

Under which account is the service started?

This account needs to have network access rights. Otherwise it will not
work.

Or you set up a specific user account for this purpose that has sufficient
rights - which would be better from a security point of view.

Following some basic information about services and access rights:

http://technet.microsoft.com/en-us/library/cc782435%28v=ws.10%29.aspx

Thomas

Thomas Braun wrote in news:mnadxh4oyaf3$.6awtpleuq3d4.dlg@40tude.net:

>> Well the drive is mapped, since I was testing it while I was logged
>> in on the desktop. I also tried the UNC name, but it did not work. I
>> think the problem may afterall be permissions since the target folder
>> has different credentials. 
> 
> Under which account is the service started?
> 
> This account needs to have network access rights. Otherwise it will
> not work.
> 
> Or you set up a specific user account for this purpose that has
> sufficient rights - which would be better from a security point of
> view. 
> 
> Following some basic information about services and access rights:
> http://technet.microsoft.com/en-us/library/cc782435%28v=ws.10%29.aspx

The service was started using the local admin account which does have 
network access rights, however it may not have rights to browse files 
located on the mapped drive. In any case, I solved the problem by copying 
the required files onto the local drive. If the customer wants to use the 
mapped drive, then they can get their IT to set up the required accounts. I 
will forward the above link to them - thanks for your help!

Best regards,
Boris Borzic

http://xb2.net
http://sqlexpress.net
industrial strength Xbase++ development tools