| Title: | PATHWORKS for Macintosh & PATHWORKS for VMS (Macintosh) |
| Notice: | Mac client 1.3.5 kit see note 9.2. MacX 1.5 kit see note 9.5 |
| Moderator: | UNIFIX::HARRIS |
| Created: | Fri Jan 26 1990 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4033 |
| Total number of notes: | 16065 |
Looking for some theories as to how this could happen.
Customer running MSA 1.3. Has old (1992) established volume. Somewhere
along the line, maybe recently, all the files in the top level
directory ended up with 0k, even from VMS. About 35 files are affected.
Files in the subdirectories are fine.
Of the 35 files, 10 have correct file type and creator info. 10 appear
as documents with a corresponding file in the MSAF$RESOURCES
subdirectory. All other files just appear as documents.
From VMS the files have 0k also. We are tyring to figure out how this
could have happened. The log file indicating nothing but we only had 1
old one to look at so the problem could have occurred earlier.
Customer is trying to find out the last time these files were actually
used. From VMS, we have varying modification dates. Creation dates are
spread out over 5 years. The files in the MSAF$VOLINFO area looks ok.
There are no errors with an ANAL/DISK, not sure if any ever occured
previous. He is not the only one to have his fingers in this.
Any theories on what may have happened?
Thanks.
jim
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 4020.1 | I suspect a Mac or OpenVMS problem | UNIFIX::HARRIS | Juggling has its ups and downs | Fri Apr 04 1997 12:39 | 35 |
No theories. Historically, we have been very good about neither
loosing nor corrupting users files. The cloested we came to that was
v1.2, which we quickly corrected with the v1.2-1 MUP and that was a
problem with not finding files while doing a folder copy, so in the
v1.2 case it was a matter of not copying a file which it didn't find,
it was not a case of loosing data.
So again, I have no prior examples of data loss but the file is still
there in the history of the product.
At this point in time my "gut" feeling is that this is a problem
outside of the file server itself (OpenVMS or Mac application caused).
Wild idea, Along the lines of an OpenVMS caused, maybe, if the disk ran
out of space and someone was running a utility on the Mac that for some
unknown reason was attempting to update the files, that maybe a new
tmp file was created, but no data could be actually written to it, the
Mac application ignored the errors, and proceeded to delete the
original, and rename the temp to the original name (a common way to
update files via the Mac). Or the Mac was rewritting the data by
truncating the file first and then when it attempted to write the new
data, it got an I/O error, but didn't tell anyone, or the user that did
it ignored the error.
Again, this is a wild guess. As far as I know we would have at the
minimum returned an error the the Mac application. I don't know if we
would have written anything to the log file.
Also the same type of problem might have occurred if the user had disk
quotas enabled and ran out of quota.
My wife just showed up for lunch, I've got to run
Bob Harris
| |||||