Hi All,
We have a batch interface that runs against a specific directory using the same OS-DIR command as used on other directories. This particular interface has been running successfully for several months - however as of the 15th OS-DIR stopped reporting the contents of the directory. If I create a file, or copy an old interface file to the directory it is visible. The majority of files coming via ftp from the partner are no longer visible in this location and moving them still leaves them invisible to OS-DIR. I can not see any difference between the files - all have the UTF-8 BOM and all filenames have the same format.
If I check these files and previous successfull files the attributes are the same, same owner and same BOM - UTF-8.Renaming the file does not make it visible to OS-DIR. Moving the file to another directory does not help either.
Before I go and ask the client what did they or the service provider change I was / am hoping that someone has encountered this and knows how to resolve it (other than resorting to difference commands for linux/windows).
Tehcnical detail.
OE 11.6 32bit TTY running on RH7.5 64bit on an xfs file system. selinux is disabled. Files are currently owned by root and rwxr-xr-x and the interface is running as the root user.
Hi PhilF,
They didn't have the + but had a . which I had ignored due to selinux being 'disabled'. I renamed the directory and created a new one that does NOT have the . in the attributes and now the files are visible and processing (i monitored for a day before replying).
Sounds like you're hitting this issue:
knowledgebase.progress.com/.../000052725 "INPUT FROM OS-DIR SHOWS EMPTY LISTING ON LINUX 64-BIT"
Hi thanks, but this is a not a CIFS share as far as I can see and some incoming files are still visible. Ill check the strace just to be sure and suggest that this client should be upgraded to 64bit OE11.6 anyway just so that out OE release is more consistent across clients.
Rather a long shot -- but do any of the files have extended permission set (as in getfacl and setfacl)? You can tell because the file permissions will have a plus sign appended in an "ls -l" listing, e.g.
-rwxrwx---+ 1 devops devops 22122 Dec 12 21:27 admin
-rwxrwx---+ 1 devops devops 24918 Dec 13 15:42 alias.cfg
-rwxrwx---+ 1 devops devops 107 Dec 12 21:27 become
I've had some weird errors with these -- though not the one your reporting.
Hi PhilF,
They didn't have the + but had a . which I had ignored due to selinux being 'disabled'. I renamed the directory and created a new one that does NOT have the . in the attributes and now the files are visible and processing (i monitored for a day before replying).