How to detect opened files in Mint/MagiC ?

[wongck]

How to detect opened files in Mint/MagiC ?

When a file is opened for writing, I can still delete it using another program.

[joska]

IIRC this is a known bug in MagiC. But does this happen under MiNT as well?

[wongck]

Yes, in Mint as well.

Program A opens a text file for writing, slowly, for 30 secs, writing 100 bytes every sec.
I can see the file created.
Program B then runs and delete the text file and exits.
Program A continues to write as if nothing had happens. On desktop window, I can see that the file turned into a folder icon !!!
Program A finally exits, and luckily the folder (which was a text file) is gone.

In program B, I test for opened file the brute force way:
1. open it for writing.... can be opened.
2. rename the file.... can be renamed.

So are there any system functions to do this properly?

[joska]

I expected Fdelete to return with an error if the file was open by another process, but I can't see anything in the implementation of Fdelete that suggest that this is the case. So the behavior you describe appears to be by design. The docs even say not to apply this function to open files.

Maybe you can use Fselect to check if the file can be written to or not.

[m0n0]

Hello,

I would expect this behavior.

At least when you didn't specify:

A.) the file sharing attributes via Fopen()
B.) Did not lock the file via Flock()

I would be in doubt if you previously locked the file with some locking system call... maybe the lock is only for informational purpose and so you have to query the locking status before deleting the file (via Fcntl()).

Greets,
Ole

[wongck]

Well, I know of the locks but it is not me that I am worry about right here.

It's the other programs... I doubt that others developer are locking them especially when the programs are done years ago.

Some background to the question:
It is really for PH Easy Remote Print, specifically the auto job submission via the watch folder.
It is suppose to detect for a file (print job saved as a file) and then submit the lpd server, after which it will delete it.
Any programs can write into this watch folder and that's where the issue is.

The thing is that I simulated a slow write to simulate the job submission. PH Easy Remote Print cannot detect that the file is still being written and submitted the job (printed out partially) and deleted the simulated file.

Sure the release version is now making some smart decisions as to when the file is completed or not, but it would be taking less resources if it can just look up a list of opened files (like in Linux or Windows).

[m0n0]

hm, I'm pretty sure it is possible by becoming intimate with the kernel

(It looks like the fd symlinks under /kern/PID/fd aren't populated completly / as expected... anyway, that would only work for FreeMiNT)

[wongck]

hm, I'm pretty sure it is possible by becoming intimate with the kernel
(It looks like the fd symlinks under /kern/PID/fd aren't populated completly / as expected... anyway, that would only work for FreeMiNT)

Was planning to have a dig at the kernel over Christmas, if time permits.
But I need something that works for both Mint & Magic.

[joska]

Why do you have to delete the file? If you use NVDI "print to file", it will always print to the same file, overwriting the previous one. So instead of deleting the file when you've printed it, you can set the "archived"-flag and check for this at regular intervals. When this flag is cleared, it means that the file has changed since the last time you printed it.

So you can use your current trick (I guess you check it's size, wait a bit and then see if the file has grown to determine if it's OK to print it) to determine when to print the file, then set the archive bit and use this to detect when NVDI has overwritten the file.

[wongck]

Actually deleting it or not does not matter, as you also know that NVDI is using the same filename and there are ways pointed by you to find this out.

Most critical is to know when it is finished writing, then the transfer to lpd server can begin.
Checking file size is only as good if the change in size happens before the next checking.
The page being rendered may be large and complex, and slow down the output to hd.
Checking the file happens before NVDI can write.... partial transfer happens.
It's not 100% fool proof, as I have written in the user doc.

Secondary issue is that the actual start of transfer to lpd may also be delayed couple of seconds.
Worst case is when NVDI completes immediately after PH ERP test. Takes one more cycle before printout starts.