Skip to main content
Question

Diretory and File Pathnames check file gdb for locks

  • December 16, 2019
  • 3 replies
  • 31 views

Forum|alt.badge.img

I am trying to implement a workflow that will check a specified FDGB directory for the presence of .lock files and use the ownership information of those lock files to email the users to disconnect so the data can be updated. The problem is that the path_ownername attribute is not being returned by the Directory and File Pathnames reader. I have tested this in multiple FGDBs and the only time I get a value for path_ownername is when I change the extension to .atx (which doesn't help) or when I use a directory that has some older (orphaned?) lock files with last modification dates of a day or more. What method does the reader use to harvest these attributes ? Perhaps there could be a security related interference or a default permissions problem

3 replies

david_r
Celebrity
  • December 17, 2019

As per the documentation, you need to activate "Retrieve file properties" on the reader for this attribute to be set:

See: https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/path/Feature_Representation.htm

Be aware that activating this option will slow down the reader a little bit for each returned file.


Forum|alt.badge.img
  • Author
  • December 19, 2019
david_r wrote:

As per the documentation, you need to activate "Retrieve file properties" on the reader for this attribute to be set:

See: https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/path/Feature_Representation.htm

Be aware that activating this option will slow down the reader a little bit for each returned file.

That is already set and it still does not return anything for current .sr_lock files.


david_r
Celebrity
  • December 19, 2019
djacques wrote:

That is already set and it still does not return anything for current .sr_lock files.

In that case it's probably something linked to the underlying technology and user permissions on that particular network share. You may want to discuss this with your IT department.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings