> In general, there's nothing in unix that prevents you from deleting an > open file either. The file gets unlinked from the directory where it had > been deleted from, but the inode continues to exist and the file remains > accessable to anyone who already had it open. When the last person closes > the file, the inode goes away.
AFAIK that is correct. On unix there is no delete as such, just unlink. When you delete a file you are really deleting a link to it and the OS will actually dump the file (and inode) when the link count for the inode drops to zero. When someone has it open, a link is maintained and so the file won't be physically deleted and the disk space made available until the file is closed and the link count drops. Perhaps someone who really understands it could confirm this. > I seem to remember that universe, and maybe unidata, had a table of open > files, and it would close and reopen unix files as necessary to avoid > running out of OS file handles. Is it possible that that is happening here? > Unidata closes the unix file, and then tries to reopen it so that it can do > the write, and fails because it has been deleted? UD behaves like this. It maintains a table of open file pointers (max is NFILES in $UDTHOME/include/udtconfig). When you have NFILES files open in your app and then open the next file, UD will close one of the existing and then open the new one and so on. Before you rush to up your NFILES though, do a ulimit -a to check how many open files you may have and ensure you keep NFILES a few below this or those "stay all night and try and fix corrupted data" problems occur. On the subject of using marker files at the OS level and sleeps etc. for locking. I have an article somewhere that recommends using a symbolic link because the first in will get it and the others will fail. touch markerfile ;* make sure it exists if ln -s markerfile lockfile > /dev/null 2>&1 ; then do stuff here else do error stuff here because I couldn't get a lock fi rm lockfile ;* clear the lock or the script won't work again It's usually a good idea to put something in the rc.local file to clear any locks on bootup as well so your system will come up clean. HTH Adrian > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Kevin King > Sent: Monday, December 20, 2004 10:56 AM > To: [EMAIL PROTECTED] > Subject: RE: [U2] Writeseq quirkiness - the answer > > > That's something of a mystery to me too. The app that Dana is > referring to is a java app that polls the directory and then consumes > anything it finds. I found it interesting that the Java app could > open a file that was being written to by Unidata, but then again, > we've seen this with credit card processing so I figured the .tmp -> > .out rename might be a workable solution in this case as well. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David > Wolverton > Sent: Monday, December 20, 2004 9:19 AM > To: [EMAIL PROTECTED] > Subject: RE: [U2] Writeseq quirkiness - the answer > > One question - why could Kevin's process delete an open file? I > thought the OS prevented that very situation from happening! Or does > UD not hold the > item open such that the OS sees it an 'in use by another process'? > It > would seem that by virtue of doing OPENSEQ, no one could 'delete' the > item until you wrote the item (or did CLOSESEQ)... > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dana Baron > Sent: Monday, December 20, 2004 8:39 AM > To: U2-Users (E-mail) > Subject: [U2] Writeseq quirkiness - the answer > > Greetings, > > And the prize goes to Kevin King! He came up with the "write" answer > to solve my writeseq problem. Of course, he had an advantage since he > helped write the application in the first place. Still, I was stumped > and his answer worked. Thank you (once again!), Kevin. > > For those who care: To understand the solution, you need a little more > background. The code segment I sent is part of an application that > manages the interface between my Unidata application and a third-party > device, which in turn manages the interface with a bunch of other > devices. When I want to send data out of my application, I create a > file with a .out extension and write the appropriately formatted data > to the file. A program written by Kevin King sits out there looking > for files with .out extensions. When it finds one, it reads the file > and sends the data to the third-party device. > It then deletes the file. And this is wherein lay the problem, and the > solution. > > What was happening was, my program would open the file (OPENSEQ) and > Kevin's program would come along and try to read it, then delete it, > then I'd try to write to it (WRITESEQ), but by then it was gone. I > changed the code a little bit to open the file with a .tmp extension, > write to that, then rename it to .out. Works great! > > There are still a few mysteries: why does the original code work for > just about every situation, then suddenly fail for one new situation > that is seemly the same as all the others? But heck, it works so I'll > go with it. > > Thanks to everyone who responded with a solution. And the u2 list > comes through again! > > Dana Baron > System Manager > Smugglers' Notch Resort > ------- > u2-users mailing list > [EMAIL PROTECTED] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [EMAIL PROTECTED] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [EMAIL PROTECTED] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [EMAIL PROTECTED] > To unsubscribe please visit http://listserver.u2ug.org/ -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
