Re: .old files being created by root

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
.

Relevant Pages

  • Re: .old files being created by root
    ... the time and date she ran the last l command. ... Could their creation be associated with the other companies script to pick ... Any idea what could be going on to block access by the other program and ... the target files and delete them. ...
    (comp.unix.sco.misc)
  • Re: [opensuse] Undoing a delete
    ... script that moves the target files to a trashcan folder. ... specified trash folder rather than simply unlink them. ...
    (SuSE)