Reference for unit 'fileshare'

Notes

The fileshare unit implements crossplatform file sharing. If multiple users are going to be writing to a file at the same time, it is neccessary to lock a file before writing to it. On linux/unix/bsd there are ways to lock a file using operating system calls - however this unit implements file sharing on all platforms (bsd/windows/linux).

If users are going to be writing and reading to a file at the same time, should also lock the file before reading and unlock the file after finishing reading. This is so that read/write conflicts do not occur. It may seem natural only to lock a file before writing to it, however you should lock a file before reading.

You should only worry about locking files for read/write if you are going to have more than one person writing and reading at the same time - for example a wiki system that allows multiple users to update the same file on the hard drive. If the wiki is database driven, you would not need to worry about file locking as the database handles multiple communications.

Warning

The fileshare unit has not been stress tested under heavy server loads. You may experience dangling LFW/LFR files and it is recommended to use a database (or operating system file locks) on busy websites instead of file locking.

The fileshare unit will be updated in future releases, or an alternative fileshare2 unit will be added and stress tested. Operating system fLock() and LockFile() routines are most likely going to be used in the next fileshare2 unit. The current fileshare unit uses code from the 1.4.x branch which the current Powtils maintainer did not write nor recommends using on busy servers or mission critical applications.

That being said, a web forum and a content manager have been written using the fileshare routines and have been running for a few years without too many problems other than occasional dangling lfw/lfr lock files once every 10 months or so.

Current Docs

See the procedures and functions link at the top of this page.

Debugging note

If your program has a 500 error, something may have crashed on your server. A file lock can get stuck on in rare cases. You must delete the *.lfw/*.lfr files in question. For example if you placed a lock on test.txt and your program crashed before that program could unlock the file, you will encounter problems. Simply delete the .lfw/.lfr files if you have issues with a file that was placed on lock once before. The file sharing system uses a garbage collector - however in exceptional circumstances the server could crash and leave dangling lfr/lfw files that aren't garbage collected in fast enough time for your needs.

We are also looking for developers to look over our file sharing routines and see if the garbage collector can be improved on the lfr/lfw files since sharing is a tough to get perfectly right. On really important mission critical applications, it is recommend you use a database since databases share data across thousands of users better than files. For simple and small wiki's or text files and simpler programs, file sharing can be really handy though.