FOLDERMONITOR created also firing for delete (and maybe other events)

[gregg]

I recently upgraded from 9.x to

TCC 15.01.57 Windows XP [Version 5.1.2600]
TCC Build 57 Windows XP Build 2600 Service Pack 3

and had to make a number of adjustments to address the changes.

One thing I haven't worked out yet is FOLDERMONITOR.

Basically I have a batch file that runs forever in the tray and uses foldermonitor:

--- fmtest.bat

@echo off
cls

SET monitor_folder=c:\fmtest
CDD %monitor_folder

ECHO Watching %monitor_folder
foldermonitor /c
foldermonitor %monitor_folder /I"*.xxx" /U created forever START /B c:\fmtest\process_xxx.bat
foldermonitor

ON BREAK GOTO Done

DO FOREVER
    REM IF NOT EXIST c:\stayopen WINDOW TRAY

    DELAY 20
ENDDO

:Done

foldermonitor /c

foldermonitor

--- process_xxx.bat

@echo off


REM IF NOT EXIST c:\stayopen WINDOW TRAY

SET log_file=c:\fmtest\process.log

ECHO -------[%_ISODATE %_TIME]----------------------------------------- >> %log_file

SET montior_folder=c:\fmtest
CDD %monitor_folder

ECHO action: %_folderaction  >> %log_file
ECHO count : %_foldercount   >> %log_file
ECHO name  : %_foldername    >> %log_file
ECHO file1 : %_folderfile1   >> %log_file
ECHO file2 : %_folderfile2   >> %log_file

BEEP
DELAY 2

REM del /y %_folderfile1

EXIT

Now, with fmtest running I go to a different TCC console window:

c:\fmtest>touch /c blah.xxx
12/26/2013 12:39:41.202  C:\fmtest\blah.xxx

I hear 2 beeps and the log file looks like this:

-------[2013-12-26 12:39:42]-----------------------------------------

action: CREATED
count : 5
name  : c:\fmtest
file1 : blah.xxx
file2 :
-------[2013-12-26 12:39:42]-----------------------------------------
action:
count :
name  :
file1 :
file2 :

Now I do:

c:\fmtest>del blah.xxx
Deleting C:\fmtest\blah.xxx
     1 file deleted

hear 1 beep and the log file now has this additional blank entry:

-------[2013-12-26 12:42:28]-----------------------------------------

action:
count :
name  :
file1 :
file2 :

There's been a lot of discussion about foldermonitor, and I read a lot of it, but didn't follow if these empty events were WAD or not. With no information being sent to the batch file on these additional events, they don't seem very useful and just kick off a bunch of additional processes that then need to check if %_folderfile1.==.

 

[vefatica]

Something seems amiss. Here's a simpler one that doesn't look quite right.
In one console:

v:\> foldermonitor t:\ /i"*.xxx" /u created forever set _f*

v:\> _folderaction=CREATED
_foldercount=1
_folderfile1=1.xxx
_foldername=t:\
TCC: Not in environment "_f*"
TCC: Not in environment "_f*"
TCC: Not in environment "_f*"
TCC: Not in environment "_f*"
_folderaction=CREATED
_foldercount=6
_folderfile1=1.xxx
_foldername=t:\
TCC: Not in environment "_f*"
TCC: Not in environment "_f*"

In another:

v:\> touch /c t:\1.xxx
2013-12-26 13:10:08.103  T:\1.xxx

v:\> touch /c t:\1.xxx
2013-12-26 13:10:44.437  T:\1.xxx

v:\> touch /c t:\1.xxx
2013-12-26 13:10:47.853  T:\1.xxx

v:\> del t:\1.xxx
Deleting T:\1.xxx
  1 file deleted

v:\> touch /c t:\1.xxx
2013-12-26 13:11:52.267  T:\1.xxx

v:\> del t:\1.xxx
Deleting T:\1.xxx
  1 file deleted

 

[vefatica]

It seems FOLDERMONITOR is executing its command and incrementing its count (but not setting variables) for actions that were not specified (modify and delete).

 

[rconn]

It is extremely unlikely (as in, probably never) that a /U will work with "created", because FOLDERMONITOR gets the creation notification before the file is accessible, and long before it is closed (even if it were created and immediately closed, as with TOUCH /C).

Combining /U and "created" triggered a bug (somewhat related) in FOLDERMONITOR where Windows returned a file handle that could not be accessed, and that's what caused the subsequent strange variables. I've fixed that for 15.01.58, which results in your FOLDERMONITOR never doing anything (which is correct given your syntax).

15.01.58 is already available on the jpsoft.com website.

 

[vefatica]

Combining /U and "created" triggered a bug (somewhat related) in FOLDERMONITOR where Windows returned a file handle that could not be accessed, and that's what caused the subsequent strange variables. I've fixed that for 15.01.58, which results in your FOLDERMONITOR never doing anything (which is correct given your syntax).

It happened without "/U" (as it still does in v14).

 

[rconn]

It happened without "/U" (as it still does in v14).

Try a FOLDERMONITOR /C before running it again.

 

[gregg]

Thanks. .58 isn't showing the additional events now.

The real application of this doesn't use touch /c, that was just an easy way for me to test. What I'm really doing is saving attachments from e-mail and based on the docs I assumed the /U meant that the event would trigger after the file finished writing. It sounds like I should add a small delay in my process script to make sure the file fully written before acting on the event.

In what cases is /U useful? What does "unlocked" mean?

Thanks again.

 

[rconn]

In what cases is /U useful? What does "unlocked" mean?

/U means "wait until I can write to the file". That doesn't usually happen until the file is closed, unless (rare) the file is opened for shared read/write.