Is there a file watcher task insdie cruisecontrol.net??? I am trying to see if I can have cruiscontrol watch a file and when the file gets updated, then runs my executable.
You probably want File system control block.
Related
say biz.log:
I read the logrotate(8) defaults to (1) rename the old log file with the date, biz.log.20220129 and then (2) create a new file with the origin name, and finally
(3) change the process's log output to the new file inode.
My question is the fact that the biz-process uses the inode instead of the file makes step1, and step2 reasonable. But how does the (3) work? I am not sure how logrotate can tell the process the log file should be reopened, and do I have to add some code to handle this in my project?
It requires cooperation between logrotate and application. Logrotate must be configured through postrotate scripts, to emit signal (i.e. SIGUSR), which application must handle - by reopening log files by their name. Actually one may also use different interprocess communication method, but i believe signals are common. See for example discussion on logrotate for httpd configuration (https://serverfault.com/questions/262868/logrotate-configuration-for-httpd-centos).
If there is no option to modify application, to work with signals for file rotation, one may configure logrotate to use copytruncate option - where logrotate copy current file to backup file, and then truncates current file to 0 bytes. If file is opened by application in append mode, it should be seamless. See https://man7.org/linux/man-pages/man8/logrotate.8.html copytruncate section.
We are currently using NLog to output to a csv file. If someone opens that file to view the contents while the application is running, nothing new is added to that file because the file is locked. Are there any NLog target attributes that would force NLog to output to a new file if the current one is locked?
What would be the effect of adding the fileAttributes output option with a value of "ReadOnly"?
If a file is locked, then the file system will reject any writes.
So the best option is there to choose a viewer that won't locks the file. It's not needed when reading.
E.g. Visual Studio Code won't lock the file and even automatisch reloads the file after a change.
Found a solution that works for us:
By setting the fileAttributes Output Option to "ReadOnly", this forces a prompt for the user when attempting to open the file with Excel and allows the file to be open in read only mode.
I have a script that takes a list of servers from an input file one by one and executes some commands on each server. I want to be able to update the input file while this script is running, without affecting the input of the first process, and re-run the script with the second list of servers. Can this be done safely?
When you run a command like file > my_script the contents located at file are piped into my_script (as a file descriptor). This decouples the contents from the name, meaning you can immediately modify/replace file in another process.
If you instead run a command like my_script file you're passing the name "file" to my_script, which may read from that file at any point (or write to it, delete it, etc.), thus you can't safely change file while the script is running. Notably this doesn't happen immediately; a long running process might not read from file until much later, after you've already edited the file.
Therefore if you design your program to read from stdin you can safely modify the input file and re-run the command while the first process is still running.
Let say that your process is running and if you want to change the file, just mv the file aside and copy your new input file. That way if the process hasn't completely read the input file into memory, it will still have a file-descriptor open to the previous file and will run unaffected. Ofcourse this all depends on how the process is implemented, if it tries to re-open the file during the course of execution, it will see new files contents.
process inputfile
mv inputfile inputfile.running
mv newinput inputfile
I need a batch file compiler that doesnt leave the source in %tmp%, so it cant be cracked that way. If there isnt a compiler that can do that, is there a way to prevent it? I have tried AbyssMedia QBFC, but it just makes the file hidden.
I agree with Hackoo: This can't be done.
A batch file is a Windows command script. Like all scripts being just a text file, also batch files need an interpreter for execution which is the Windows command processor cmd.exe for all versions of Windows NT (NT4, 2K, XP, Vista, ...).
All bat-to-exe converters simply embed the batch file compressed or even uncompressed into an executable. The created executable extracts the batch file into directory for temporary files and execute it as process resulting in being interpreted with cmd.exe.
So what all those bat-to-exe tools do can be done for example also with WinRAR by creating a self-extracting RAR archive which on execution extracts the batch file (and other added files) automatically into temporary files directory and executes the batch file which as last line deletes itself.
In other words bat-to-exe tools are completely useless tools in my point of view. SomethingDark is right: bat-to-exe converters are garbage.
I am running a small inotify script that sets up a watch on a file. Each time that file is edited and saved, the script notices that a DELETE_SELF event is triggered. Is that normal and if it is why? Shouldn't the inotify subsystem notice that the file still exists?
It depends on what the application that is editing the file is doing with it. In this case, it sounds like the behavior of your editor when it saves a file is to delete the old file and write the new contents as a new file with the same name. From the perspective of inotify, this is exactly what happens, so it fires a deletion event and then a creation event. Inotify cannot know that the file that was deleted and the file that was created in its place are logically related.