Y'all are really taking all of the fun out of this. Here's the point - this is an exercise. There is no good reason to do this. What, you've got a 10 meg disk that is at 95%? Well, if you pay shipping, I've got a extra 40 meg that I use as a book end that I'll send you.
Keep the files or delete them, but you've got no good reason for worrying about them - do you clear your browser's history (cache, etc) because the store has too many files? This is fun, and that's it. On Tue, Jul 2, 2013 at 6:37 PM, Joel Rees <joel.r...@gmail.com> wrote: > On Wed, Jul 3, 2013 at 6:28 AM, shawn wilson <ag4ve...@gmail.com> wrote: >> >> On Tue, Jul 2, 2013 at 5:14 PM, Lisi Reisz <lisi.re...@gmail.com> wrote: >> > On Tuesday 02 July 2013 22:06:17 Yaro Yaro wrote: >> >> On Jul 2, 2013 3:49 PM, "Hendrik Boom" <hend...@topoi.pooq.com> wrote: >> >> > There are lots of .dotfiles cluttering my home directory. >> >> > >> >> > No doubt some of them are useful. >> >> > >> >> > Many, though, are probably remnants of packages of years past -- >> >> > packages >> >> > I installed long ago, no longer need, and have removed. >> >> > >> >> > Is there any way of identifying which packages are using which >> >> > dotfiles? >> >> > > > You're thinking too hard. How about No, see above - he asked how to find which packages are using files. Not files he's currently using. Even my reply that showed that it would be better to do this with git missed the point. > > ls -lartd .* > Yeah, not the answer to the question. > >> >> Use a tool that shows what files are being accessed (like fuser, but >> you'll probably have better luck with strace or gdb) and use some >> expect like language (or IPC) to fire up the command (either through >> strace or gdb or quickly attach gdb to it) and see what files it looks >> for. >> >> Easiest would probably be to: find / type f -perm +111 | while read f; >> do dotfile-scraper $f; done >> >> I think the easiest is 'strace -f -s 1024 -e trace=stat64,read' and >> run until the volume of output decreases and then just kill the >> program (probably as a test user so you don't corrupt your own stuff). >> >> I don't think this is the answer you were looking and doubt you'll >> pursue this but, as I said, if you do I'd like to see the script / >> what you find. > > > I think you're just looking for an excuse to use the low-level stuff. ;-) > Well, like I said, this would be a fun project and after all, there's no good reason so we're all just masturbating here anyway. > > The "real" solution kind of points to something we need to do -- sandboxing > all apps, making them tell the system who they are when they want to drop > persistent store, maintaining a database of legitimate apps and their > persistent store. > I don't like lots of apps being sandboxed - your shell for instance has .profile, .bashrc, .bash_history, and others (I use zsh so I forgot). You could sandbox each user into their own chroot and each app into their own chroot but then when I go to open my .bashrc with vim, I need to figure out where the per session root is for my shell and cross polinating history (ctrl+r in bash i think?) doesn't work. It's a stretch on what you're proposing, but all in all, I hate the Apple approach to this (I don't remember who, but I remember reading about someone needing to jump through hoops and build their own glx or something for acceleration to work with this model). Cellular phones being another example of your proposal (and I *hate* working with all of those systems too - Nokia might've been onto something but they had gaping security so lets leave them out of this, shall we?). There is tripwire, ftimes, some internal kernel stuff (don't remember what it is called in >3.4 iirc) to look at a hash table before running programs. There are also SELinux hooks for most things you could want to regulate (which, if developers made SELinux policies for each of their apps, this might work great but they'd suck at it, so lets not try to champion that). If you want to look at this outside of the kernel, strace is what you use (but it's slow - I think even BSD's version is a bit less than native as well). I agree that it would be nice to have finer grained control on what applications do (especially from a non-uid0 login). I don't think that your proposal is the right answer. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAH_OBidWcg32b+idYFYvFE0VajF+5VT0TkR=7tjf6n0xzr7...@mail.gmail.com
