Re: .old files being created by root

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
how they delete the files from the OSR directory and the company that
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.

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


.

Relevant Pages

  • Re: .old files being created by root
    ... 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. ... The .old files are re-dated every time she runs the list command and thay always belong to root with limited access to others. ... If the client's l is a shell script, check it out to see what it is doing. ... the target files and delete them. ...
    (comp.unix.sco.misc)
  • Re: [opensuse] Undoing a delete
    ... Only with tremendous luck and heroic effort could you hope to recover ... the contents of the file to which you applied the stock "rm" command. ... that a trashcan folder would be standard. ... that moves the target files to a trashcan folder. ...
    (SuSE)
  • Re: [opensuse] Undoing a delete
    ... script that moves the target files to a trashcan folder. ... specified trash folder rather than simply unlink them. ...
    (SuSE)
  • Re: [opensuse] Undoing a delete
    ... Only with tremendous luck and heroic effort could you hope to recover ... the contents of the file to which you applied the stock "rm" command. ... that moves the target files to a trashcan folder. ...
    (SuSE)