@Warren> It was mentioned in another thread, of this exact subject (I think this is the third thread?) that the package/sandbox idea won't work due to certain constraints the OS puts on the file. I don't recall what the reason was, exactly, as I've never used a Mac for any kind of considerable amount of time. I've never installed a program/package/whatever on a Mac so I don't know the rules or the full terminology.
@OP> Being that I'm a Windows Only developer, I've never had to run into this problem. If something has its hand on the file, it holds it in place. I absolutely make sure 100% that while my applications are running, a file handle is on the database file itself to ENSURE issues like this just do not happen. If someone comes along and changes file and/or directory permissions while my programs are running, well, they're out to sabotage their data and I'm not interested in their affairs. We've already been over the differences between EXTFS and NTFS differences, OS level handling of file management, etc. all in another thread. The issue you're running into is going to be at the application level, not at the DB level. SQLite cannot, and will not, be your savior in this case. My apologies to Dr Hipp and the rest of the development crew but file handling in SQLite is extremely stupid, and I feel that this is the way it SHOULD be. File handling is NOT SQLites responsibility, but your applications responsibility in knowing how the OS handles itself. I think you're expecting too much out of "preservation of data". Even with MySQL, if you start messing around with directory structures, file permissions, or whatever, you're GOING to kill the software. If you deny write permissions to the required directories (Assuming MySQL isn't running as root) you're going to find yourself in a world of hurt. Mind you end users may not have access to MySQL database files as typically those live on another machine, but the fact remains that even THAT software is going to start going stupid and potentially get corrupted if someone starts moving files around. Taking this conceptually down to a USER level, instead of an ADMIN level, I'd recommend doing any or all of three following things; 1> At application start, remember what path the database lives in by storing that filename in a string. Any time the database is to be accessed, verify that the path and file to the database actually exists before any kind of SQL action happens. If the file does not exist in the path required, close/terminate the program, notify the user, and slap them on the wrist next time. If you even want to go so far as to TOUCH a file to make sure you have write permissions to that path, be my guest. 2> Notify the user, in an email, person to person communication, on a web page, or whatever the best method is in your case, that if the database is moved while the application is running, they're responsible for the corruption as they are not using the program as expected. 3> Use the Backup API and work the database out of memory instead of the file system. When the user closes the application, prompt to save, and save where required. If the path doesn't exist, open up a "SAVE AS" dialog and have the user save where they need to via the Backup API again. If the database size in question is large, use the backup API and put the database somewhere else that the user doesn't expect (IE: Random file name in a temporary directory) and work off that. You have no other options beyond that. SQLite has to work under many different types of operating systems, many of them Linux based using the EXT type file systems, as well as Windows based using anything from FAT8/12/16/32/NTFS, as well as others that don't fall into the either camp. SQLite has ZERO control over the file system. It hands off handling of the file to the operating system. SQLite tells the operating system "I need to write this data out" and the OS talks to the controller on your hard drive, asks for data to be written, the drive physically writes the data to the drive, the drive tells the OS the result, the OS then tells SQLite the result. The drive doesn't talk to your software. You cannot ever expect to cover every single instance of preventing corruption under your program. Your users must follow rules, and although it is great that you're looking to prevent the corruption, you need to look further up the chain from disk level access to user interaction. On a personal note, I still cannot fathom why anyone would WANT to do file management while working on an active document. Moving a document while its being worked on contradicts everything I understand. * If I were working in a garage on a car, I'd start work on it in a certain physical place, be it on a lift, or on the ground, or at least in a certain bay. If I need to move it to another bay, I get the car into a condition that I can safely move it, do the move, then resume work when ready. If I turn my back to get a wrench and someone moves the car on me, I'd be pretty concerned if the tires weren't actually bolted on yet. * If I'm playing a game on my cell phone, and I put it down to go get a drink and one of my kids move it, I'd be pretty pissed that my game is lost and phone is gone. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
