I have an odd, intermittent bug that is happening on a web server.

One of the methods triggers the creation of a small file (3kb), in a folder. The folder is based on the current year, month and location id.

The file is created by a 3rd party component that I have no control over, other than by calling its CreateImage() method.

The developers of this component have confirmed that they hand the creation of the file over to the OS and then return without checking if the creation happened. (Nice).

What we then try to do is to open this file, and write a specific authorisation code on it. However, occasionally the log files are catching a System.ArgumentException: Parameter is not valid when I call Bitmap bmpImage = new Bitmap(filename); According to MSDN this exception means that the file is not an image file, or is not actually there.

I can't affect the 3rd party component, But I am pretty sure that Running a FileSystemWatcher on a website process is not going to cut it either, nor is any kind of blocking call where I wait for an unknown amount of time for the file to be created. The only other solution I can think of off the top of my head is to check if the file is there, if not, check after a second, and then a third time. If after all that it is not present, to throw an exception. But that just feels more like a 'bodge' than a fix.

I can't put these image creations and alterations into some kind of queue or other process, as the updated image is displayed back to the user on the next page.

Have I missed any obvious solutions to my problem here, before I need to go back and try to re-invent the whole process (Which seems overkill for maybe 1 in 500) images causing a problem?

  • "Open-ended" isn't the criteria for posting here. See softwareengineering.stackexchange.com/help/on-topic Commented Nov 20, 2017 at 16:43
  • 1
    As to your problem, you would fix it the same way you fix any other problem of this kind: wrap it in a retry mechanism if it fails? Commented Nov 20, 2017 at 16:45
  • I accept that is probably where I will have to go with this, but like I have said above, it feels more like a bodge than a fix. However, not every problem need have an elegant solution I guess!
    – Matt
    Commented Nov 20, 2017 at 16:52
  • 2
    It's not elegant, but it has the distinction of not requiring you to re-invent the whole process. Commented Nov 20, 2017 at 16:53
  • Do you know for a fact the the exceptions are in fact caught by proper image files and not what looks like being image files ?
    – frostings
    Commented Nov 21, 2017 at 9:01

2 Answers 2


If you create a system of different components which you don't have under your control, at a certain level of complexity some of the components will fail sometimes. That is especially true when your system involves several machines, hardware and networks, but can sometime also happen on just one machine.

The only sensible approach for this I know is to make your software more robust and fault-tolerant. Retry mechanisms are a standard way to do this (as well as redundancy), they are not a "bodge", as you called it. Here is an example (Apache Flink) for another system which creates robustness using a retry mechanics. Maybe it you can solve your problem in a similar manner.

  • Absolutely agree.
    – frostings
    Commented Nov 21, 2017 at 9:00

To answer the question in the title:

Detect when a file is created (on a webserver) ?

It is obviously file system and operating system specific.

However, most web servers are running some variant of Linux today. Then, if the file system is local (not a remote one like NFS or CIFS) and proper to Linux (e.g. ext4, BTRFS, XFS, ... but not VFAT or NTFS) then you could consider inotify(7) facilities to detect file creation.

You might use the inotifywait(1) & inotifywatch(1) commands or the incron daemon (or code your own program above inotify related system calls).

  • Apologies, I missed that out. It is a Windows server.
    – Matt
    Commented Nov 21, 2017 at 10:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.