1

I was surprised by a hard link created suddenly between a config file that I (as usr1) own and a temporary file that I create in an OS daemon (each 5 minutes), to copy from the original config file.

After copying back to the original file, I use rename(*file2, *file1); in C which kills any trace to config.txt.tmp

The directory is root owned on a mnt /sram drive, and no one has a root access over the embedded machine. The storage media is NAND flash SRAM on embedded Linux 2.6.10

ls -l shows 

2 config.txt       699byte date_modify  
2 config.txt.tmp   699byte date_modify

config.txt.tmp should get created, copied from config.txt, send config parameters to config.txt then gets deleted atomically within 5-7 C lines only

The directory is root owned, and there is no way to create hard links.

Anyone has an explanation of "hard link" creation in the low level functions? Could I be facing a race condition? Or could it be some kernel code for storage over flash? Or a bug in Linux?

My code ran over 5 years, 100 machines, and ONLY 1 machine recently got this problem.

Mat
  • 202,337
  • 40
  • 393
  • 406
edward george
  • 41
  • 2
  • 3
    It isn't clear from your various prose descriptions what operations are being done on what files. Could you make it, like, _exceedingly_ clear? Use _exact filenames_, identify processes involved in each action, list the steps _in sequence_, POSIX funtion names instead of 'send config parameters to config.txt' (you ***cannot*** send text to a file, perhaps to a socket), and what does 'atomic deletion' mean, especially seeing that it takes multiple lines? – sehe Jul 18 '12 at 00:21
  • I amended my answer with more info – sehe Jul 18 '12 at 00:36

1 Answers1

1

Check whether the files are actually hardlinks by doing

ls -i

to show inodes.

Of the top of my head:

  • file buffers may have been dirty before move?
  • if a fork is involved, again, dirty buffers may be at play even from before the fork
  • is a flash 'overlay' filesystem driver present? Perhaps it has changed and contains an optimization that it previously didn't
    Think
    • unionfs
    • aufs
    • ...?

Edit

FWIW: From your text, I get the impression you might be doing things in reverse: I'd expect you to write to a .tmp copy, and once everything is flushed & synched, 'atomically' (well, cross fingers for filesystem support and ordering mode) rename it into place. (I'm just guessing now, because most of the picture is too hazy to actually go on)

Also see: Is rename() without fsync() safe?

Community
  • 1
  • 1
sehe
  • 374,641
  • 47
  • 450
  • 633
  • sehe sorry for the late response, yes I see the same number referencing those two files after ls -i. I am thinking like this - only less than 50 units are suffering that out of 100s of thousands - I dont believe it is about the file system itself. I am expecting the app from a certain programmer opens those files and does some certain function call sequence. But the trouble is NOONE gives his code. Any ideas? thanks – edward george Sep 14 '12 at 15:44
  • perhaps strace/ptrace can shed some light on what other programs are doing - if you can't get the source. OllyDbg/WinDbg on windows – sehe Sep 14 '12 at 16:04