Andrew Wallo
13th November 2008 19:46 UTC

Onname Filenames not null-terminated.Windows FindNext FindFirst Fails with zero files
Potential bug in the File \onname feature of NSIS.

The following code was used to create 2000 dummy emails for stress testing an email program. ( You would need to provide dummy email files to pass compile... ) I had four files, a clean pair and a dirty pair. ( not really important, just FYI when you read the code. ) odds became clean, even numbers dirty, in the loop.

The problem was that the program that was being used to call the email filter ( out of scope but C++ gnu compiled. ) used WINAPI's FindFirst, FindNext functions to trigger its activies when a file arrives in the folder.

I was running XP Pro and came upon this nusiance. There is a documented error with WINAPI FindFirst and FindNext such that it fails and returns a null set when the names in the directory are not null terminated properly.

The trigger program was NOT finding these files when I dumped the files made by the following script into the spool.

Renaming the files after they were created caused the trigger program to beable to grab the files.

I altered the script to dump out the file without the /onname feature, and then renamed the file with Rename.

The files were fully functional and worked with the other program without any problem.

Therefour I humbly submit that the output of File /onname fails to add a \0 to the end of the string of the file names.... and it will cause problems when files created by it are scanned or listed or used by other c++ programs.


Can someone please confirm this as a noted bug?

Thanks,

Andrew Wallo
Avid NSIS developer.

Function .onInit

  Var /GLOBAL pathHandle

  StrCpy $pathHandle "C:\FakeEmailFolder\"
  CreateDirectory $pathHandle 

  Var /GLOBAL counter
  Var /GLOBAL oddOrEven 
  StrCpy $counter "21000"
  Var /GLOBAL dtafilename
  Var /GLOBAL ctlfilename
  
  SetoutPath $pathHandle
  ${while} $counter < 22000

   IntOp $oddOrEven $counter % 2
   StrCpy $dtafilename "0000$counter.dta"
   StrCpy $ctlfilename "0000$counter.ctl"

   StrCmp $oddOrEven "1" 0 Doclean
    ; USING FILE ONNAME creates filenames without nullterminated filenames.
    ;File "/oname= $dtafilename" "DirtyDTAFile.dta"
    ; HAD TO WRITE OUT AND RENAME TO CREATE WORKAROUND.
    File "DirtyDTAFile.dta"
    Rename "DirtyDTAFile.dta" $dtafilename
    ;File "/oname= $ctlfilename" "DirtyCTLFile.ctl"
    File "DirtyCTLFile.ctl"
    Rename "DirtyCTLFile.ctl" $ctlfilename
    Goto LoopAgain
   Doclean:
    ;File "/oname= $dtafilename" "CleanDTAFile.dta"
    ;File "/oname= $ctlfilename" "CleanCTLFile.ctl"
        File "CleanDTAFile.dta"
    Rename "CleanDTAFile.dta" $dtafilename
    ;File "/oname= $ctlfilename" "DirtyCTLFile.ctl"
    File "CleanCTLFile.ctl"
    Rename "CleanCTLFile.ctl" $ctlfilename
    

   LoopAgain:
    IntOp $counter $counter + 1
  ${endwhile} 

FunctionEnd

kichik
14th November 2008 08:10 UTC

We simply call CreateFile in either case. I can't see how that would work without a NULL terminator. Can you point me to the description of this FindNext bug?

And even though it's probably not your monitoring program, I'll just add that using FindFirstChangeNotification is a way better method than checking the directory structure in a busy loop.