# who/what created file?



## bbzz (Jan 26, 2012)

I noticed that occasionally an empty file is created in my home directory:


```
-rw-r--r--  1 bbzz  bbzz  0 Jan 26 16:05 0
```

It is possible that one of scripts I wrote creates it. It never gets filled or anything, just sits there. When I delete it, it gets created again.
My question is, how can I find out what process/program creates it?

Thanks


----------



## _martin (Jan 26, 2012)

If it reappears in a regular manner it might be a scheduled job - check the cron/periodic tasks. Timestamp of the created file can give you a key which scripts to check. 

But then you have to share that script because it's very hard to guess 

You can use sysutils/fuser or sysutils/lsof from ports to check if the file is currently opened by any process.


----------



## Beastie (Jan 26, 2012)

Is it actually called "0"? If not, then sharing the real name may help someone recognize it.

As mentioned by matoatlantis, I'd look into cron/periodic, as the home directory seems like a weird place to put temporary files and conf files should be easily recognizable from their names alone.


----------



## redw0lfx (Jan 26, 2012)

I tend to sometimes have that issue with files created as '1', but its usually because I was redirecting STDOUT and STDERR and accidentally forgot the '&', example: 


```
./myprog >somelogfile 2>1 (notice the 2>1 instead of 2>&1)
```

However, adding to what others have said, if its called '0', and based on the timestamp, perhaps check your cron jobs and see if any of those scripts run as your user.


```
crontab -e
```


----------



## freethread (Jan 26, 2012)

And in login shell scripts. It happened to me too, use of single/double quotes with variable expansions... _ad minchiam_. It was in .cshrc in alias postcmd, the file was always created, if it's in an user-defined alias the file is created only when alias is used.


----------



## bbzz (Jan 27, 2012)

Found it. It was one of scripts running with .xinitrc. Parenthesis were at the wrong place so instead of checking "greater than 0", output got redirected to "0".

It was really annoying not to know where it was coming from.

Well, thanks all


----------



## fonz (Jan 27, 2012)

Saved you the trouble of having to "booby trap" the kernel by hooking the open(2) system call


----------



## DutchDaemon (Jan 27, 2012)

Well, he could also have made that file immutable with chflags(1) and watch which script would complain


----------



## bbzz (Jan 27, 2012)

Aha! Some good advices here, thanks.


----------



## fonz (Jan 27, 2012)

DutchDaemon said:
			
		

> Well, he could also have made that file immutable with chflags(1) and watch which script would complain


That _is_ indeed an easier solution DD, I'll give you that. I think mine is more fun, though. :e

Fonz


----------

