From: Jim Starkey Date: December 11 2008 3:48pm Subject: Re: [Fwd: Bug 32398] List-Archive: http://lists.mysql.com/falcon/301 Message-Id: <49413640.1020502@nimbusdb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think it could be made to work using a second account, the restricted deletion bit (aka the sticky bit), and a minor piece of magic to change back the file owner, but at best would make it inconvenient, not impossible, to delete table spaces. Now, on VMS, there was an explicit privilege for that sort of non-sense. It was sometime asked what the point of prevent a user who could truncate a file to nothingness from deleting the file, and what was the point of having a file that someone could write but not read. Now, as for VMS, I still have a product being peddled there (HP's Datatrieve on the Itanic), but I wasn't foolish enough to give them an open ended consulting contract. Among my profession principles are: 17. I don't program 16 bit computers 47. I don't do VMS even if renamed OpenVMS Sorry, if you want to do VMS, you're on your own. Vladislav Vaintroub wrote: > Changing file attributes seems too sneaky for me:) > removing write on parent directory is bad, as it makes creating file in the > directory impossible. Playing with file attributes requires specific file > systems (except on Windows) and does not have documented apis (again except > on Windows) > > So I'd say, for the purpose of the bug fix, adding ".fts" extension if it is > not already there does not sound too bad. And, the file systems I know of, > can all swallow > multiple dots in the file name (on VMS it could not be the case, but we do > not port to VMS in the next century I hope;) > > > >> -----Original Message----- >> From: Sergey.Vojtovich@stripped [mailto:Sergey.Vojtovich@stripped] On >> Behalf Of Sergey Vojtovich >> Sent: Thursday, December 11, 2008 2:33 PM >> To: Jim Starkey >> Cc: Ann W. Harrison; Vladislav Vaintroub; 'Kevin Lewis'; >> falcon@stripped >> Subject: Re: [Fwd: Bug 32398] >> >> Hi Jim, >> >> it would pretty nice to create files without delete permission, but how >> is >> it achievable? E.g. on linux/ext2 there're two options: unset parent >> directory write access or use chattr +a. Both seem to be something >> that we can't use. >> >> Anyway... any decision on this issue? Does anybody want to say the >> final >> word? :) >> >> Regards, >> Sergey >> >> On Sat, Nov 29, 2008 at 04:30:04PM -0500, Jim Starkey wrote: >> >>> Ann W. Harrison wrote: >>> >>>> Kevin wrote: >>>> >>>> >>>>>>> I am in favor of adding .fts automatically to tablespace file >>>>>>> >> names >> >>>>>>> that have no extension, and it seems that so is Ann. >>>>>>> >>>> Actually, I'm in favor of adding .fts to all tablespace file names >>>> that don't already end in .fts. So tablespace.awh would become >>>> tablespace.awh.fts, and tablespace.MYI would become >>>> >> tablespace.MYI.fts. >> >>>> What I don't know is whether there are any supported operating >>>> >> systems >> >>>> that are strict about the number of extensions on a file. DOS did, >>>> and so did VAX/VMS, but those are both ancient history, saints be >>>> praised! >>>> >>>> Vlad wrote: >>>> >>>> >>>>> The thing with the bug is that so far there is nothing falcon that >>>>> >> would >> >>>>> prevent creating tablespace named t1.MYI or t1.par or whatever >>>>> extensions >>>>> server is using for different purposes. >>>>> >>>> Maybe we could prevail on the server not to delete pre-existing >>>> >> files >> >>>> when creating tables and partitions. We don't delete pre-existing >>>> files when creating tablespaces ... >>>> >>> Maybe we should get sneaky and create all Falcon files without delete >>> permission, turning delete back on when we are good and ready to >>> >> delete >> >>> files. Any reasonably privileged user could do the same thing, but >>> >> he'd >> >>> have to think twice about what he was doing. But it will protect >>> >> Falcon >> >>> users from the server unless the server picks up the same trick. >>> >>> >>> -- >>> Jim Starkey >>> President, NimbusDB, Inc. >>> 978 526-1376 >>> >>> >> -- >> Sergey Vojtovich >> MySQL AB, Software Engineer >> Izhevsk, Russia, www.mysql.com >> > > > -- Jim Starkey President, NimbusDB, Inc. 978 526-1376