On Monday, July 1, 2002, at 09:52 , Kipp, James wrote:
>>>> anyone know of a way to determine the user who last accessed or >>>> modified a >>>> file ? >> >> In general, anything you want to know about a given file is available >> thru the stat() function. >> http://www.perldoc.com/perl5.6.1/pod/func/stat.html > > anything BUT what i need above. The problem you just ran into is the fact that there is no 'systemic' method to implement your idea - without functionally rewriting the specifications for an Inode. If you need to manage files at that level - you will want a decent source code control system that allows check out, check in, and requires a username associated with those behaviors. So here is a part of the system nightmare to think about and freak when you have time. Any 'system wide' solution would of course need to include executable programmes - which means that you face the really fun problem when your OS allows solutions like: one instance of the executable is loaded into memory with multiple references to that one instance in a context structure that includes at least pointer to the executable in core the line in code the 'registers' point to the 'data space' of this context Which is a neat enough idea - since you only need to have one copy of the 'code' segment of 'vi' running on the machine, with multiple 'data spaces' - and this 'context thingie' - which, well you use to load stuff into the CPU and unload from the CPU. Now try to imagine how, with at least two people running 'vi' when do you update the last used by field in your new and improved file system model???? Should you build that with an additional field: Still In Use By and when do you sync those back into the file system??? On the other side of your horror - what about the update of 'access time' problem we all face with things like 'find' - and do we - in this new and improved play - update the info about 'last user' with the UID or EUID..... and how do we tell the difference between things like oh ufs_dump and stuff like when a Terran Infests the File???? Alternatively you could think in terms of adding in say a 'resource fork' to shadow all files - that would include all of your information - but that still would mean updating all of the code that would ever be able to access the file... I think that the source code control system would be easier to use than trying to a) build a whole new journaling file system b) re-build all applications to this new standard. But If you want to try it in Perl GO for it - since it would be interesting to see kernel modules that used embedded perl in them.... ciao drieux --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]