×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
We are having an issue with files stored on the IFS occasionally having
their attributes changes to "Hidden" and "System". It appears to be
happening through some action on the PC, but we haven't been able to track
down the cause. Multiple users have had the issue and it happens to less
than 1% of the files that are accessed. The files are almost exclusively
*.tif and most users use some form of the MS Picture Manager for viewing.
Has anyone had any issues with PC based programs "accidentally" changing
the attributes of the files? Under normal circumstances, setting a file
to hidden or system would be something a user would have to intentionally
do through File Properties....not something that happens through a display
app like Picture Manager.
The original files are stored in a secure folder. When the user requests a
file, a job is submitted using the necessary authority to copy the file
from the secure folder to a public folder. Although it shouldn't be
necessary, the job also sets public authority to the file. The interactive
job then performs the STRPCO and executes the START command allowing the PC
to display the image in what ever PC App the user has associated to that
file type. The last step of the process is to submit a job (with a 30
minute delay ) to delete the file from the public directory. This keeps
the public directory clean.
We discovered the problem when a user complained he was looking at an old
image and not the latest release. After playing with the WinExp settings
on my PC, I discovered there were actually about 20 files from various
dates in the public folder. One was the image in question. It was left
over from 3 months ago and it's presence and attributes caused on error in
the copy program. But since the file was in the public folder, STRPCO &
Start had no problem displaying it.
Two plans for a work around.... 1) add a MonMsg and CHGATR to the copy
program so that if the error occurs, all the attributes are set to "public"
setting and the copy occurs again. 2) in the copy, rename the file using
the current user name and date as part of the name so that each file is
uniquely named (at least within 24 hours). Both of these steps seem to
get around the problem but neither answers the question of what function is
occasionally changing the attributes in the first place.
Any thoughts would be appreciated.
Paul Thieme
Hutchinson FTS
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.