Within bash this works:
mkfifo afifo
cat small_file > afifo
od -x afifo
#expected contents shown
However, after:
cat small_file > afifo
in a test program which does just this
//len_file is size of small_file
fin = fopen(file_name,"rb");
char *buffer=malloc(len_file);
rlen = fread(buffer, 1, l
Found a way to do it based solely on CreateFile(). If that is called
with GENERIC_READ | GENERIC_WRITE it will fail if some other program has
the file locked. There does not seem to be
a CreateFile() with a wait so a loop was put in with .01s sleeps. That
did not cause a noticeable CPU load
On 2020-01-10 02:05, Gisle Vanem wrote:
David Mathog wrote:
The test program just tries to lock, and then unlock that file. It
should do so 3 only
after the subprocess releases its lock.
Have you tried '_locking()' or '_lock_file()'
for your Windows version?
Ref:
https://docs.microsoft.c
David Mathog wrote:
The test program just tries to lock, and then unlock that file. It should do
so 3 only
after the subprocess releases its lock.
Have you tried '_locking()' or '_lock_file()'
for your Windows version?
Ref:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/l
