Re: .old files being created by root

DAW wrote:
The question from Steve- "Picked up how?"

The external program running on another server but connected to the overall system network apparently picks them up with an ftp program. I have no idea

Well if it is via ftp, then there will be a record of the ftp login attempts.

Run last | grep ftp and post that result.

Also, check /usr/adm/syslog for ftp records. Does that show anything interesting?

how they delete the files from the OSR directory and the company that

When logged in via ftp, you can delete files with the "delete filename" command.

Since it is via ftp, the other end must be running a script (not a human logging in
to copy/delete files) then my suspicion that the script is simple minded and
does not handle unforeseen conditions like the target and target.old files coexisting
at the time the script executes is more probable.

The other possibility is that the identity used to login via ftp has had the
account password changed and the script trying to pick up the files has not
been updated to use the new password.

Have the client execute "ftp localhost" and use the expected login name
and password. She should be in the target directory or some directory
above it so that she can use cd to move down the directory path to the
target directory. If that does not work, then the script won't work.


provides that program is now in the mode that you have to go through two "front men" before you can even talk to a programmer. Not only that, the programmer I knew there when we created the interface is probably no longer there. That's most likely the reason they have these "support" guys who take questions, pass them to someone else, and then come back with another question.

Have the client answer the rest of my suggestions in my first response.
Then post the results. Since we are trying to diagnose this third hand,
you must answer each of the questions as they all may shed some light
on important information.

So far your answers to the items I suggested you investigate, and gazing
into my crystal ball, allow me to tell you that the ocean is blue.
Not much help with your problem.

Also, you never said if this is an SCO UNIX OS or Linux or some other UNIX.
Post the results of uname -X.


DAW

"Steve M. Fabac, Jr." <smfabac@xxxxxxx> wrote in message news:49301F1B.7060702@xxxxxxxxxx
DAW wrote:
I wrote a program for a medical practice that reads an activity file and exports certain data every five minutes, assuming there are appiclable transactions. Those files are then picked up by a third party and processed, with the files they pick up then being deleted by the other companies program.
Picked up how?

This has been running happily for a year or so. Last week the other company said it could not find the export files, which have names of the form:

yyyymmddhhss.tum

When my client looks in her output directory she finds those files, but she also finds, for EACH of the files, a second file with the name form:

yyyymmddhhss.tum.old

Now it gets interesting. The .old files have a Unix date stamp that is the time and date she ran the last l (list) command. The .old files are re-dated every time she runs the list command and thay always belong to root with limited access to others.
>>
Someone aliased the l command with their own shell script that creates
or touches the .old files?

I thought the .old files were not real, but they are, they can be doscpied to a floppy and emailed to me. Each is identical in size and content to
it's matching export file, just having the .old added to the name.

Could their creation be associated with the other companies script to pick
up the target files? A safety precaution copying the files to .old before
deleting the target file?


Everything has been clean re-booted, that is the OSR system and the other companies program, which is running on another computer but sitting on the
overall network.

Here is a piece of the list she sent me:

-rw-rw-rw- 1 medmaint group 1230 Nov 24 15:44 P20081124154438.tum
-rw------- 1 root sys 1230 Nov 24 16:05 P20081124154438.tum.old*
-rw-rw-rw- 1 medmaint group 1017 Nov 24 15:49 P20081124154938.tum
-rw------- 1 root sys 1017 Nov 24 16:05 P20081124154938.tum.old*
-rw-rw-rw- 1 medmaint group 125 Nov 24 15:54 P20081124155438.tum
-rw------- 1 root sys 125 Nov 24 16:05 P20081124155438.tum.old*
-rw-rw-rw- 1 medmaint group 2305 Nov 24 15:59 P20081124155943.tum
-rw------- 1 root sys 2305 Nov 24 16:05 P20081124155943.tum.old*
-rw-rw-rw- 1 medmaint group 1148 Nov 24 16:04 P20081124160443.tum
-rw------- 1 root sys 1148 Nov 24 16:05 P20081124160443.tum.old*

(Sorry about the alignment, I couldn't find a fixed pitch font. )

Note that the .old files have the time stamp of 16:05. If she does it again, the original files, ending in .tum have their original unix time stamps, but the .old files are modified to the time she does the list. *For example 16:05 would change to the new time she runs the list command.

Any idea what could be going on to block access by the other program and what can be causing the .old files to be re-dated?
>>
Block access? Again how are they "picked up"? Run type l to see what file
is being executed. On my 5.0.7 I get:

$ type l
l is /bin/l
$ file /bin/l
/bin/l: ELF 32-bit LSB executable 80386, dynamically linked, stripped, n
o debug
$

If the client's l is a shell script, check it out to see what it is doing.

The other company asked me how the directory was mounted. I didn't install the SCO system and don't know who did. I have no idea since I have never been on site and they installed everything onto the existing Unix system.
>>
What is the path to the directory? Does the process that "picks up" the
files belong to a user that has access to that directory? Run ls -ld on
each directory above the target directory back up to the root directory.

Someone may have run custom -> software -> verify system -> quick and
allowed it to patch the permissions on a directory up the path from your
target directory.

By the way, no one admits to making any changes on the date the link stopped working, and in the meantime my program keeps on cranking out a new file
every five minutes as it has for a year.
>>
Looks like your program is performing as expected. This looks like the other
company's problem as you are not handling the piece of the task to "pick up"
the target files and delete them.

Likely their script is getting confused with the target and .old files still hanging
around and just blows up as the programmer did not anticipate the condition.

It may have been caused by one failure to remove the target file leaving both
the target and the target.old (communication failure, system reboot in the middle
of processing the directory) and since then, the script does not function as
the programmer intended.

Any hints would be appreciated, this has to be a simple problem.


--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
.