[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: (followup) Re: [despammed] Best way to recursive folders?
From:       tech () bishop ! dhs ! org
Date:       2003-05-05 0:00:48
[Download RAW message or body]


But on the other hand, in order to save diskspace I have several
directories of desktop backgrounds symlinked in my home directory
(rather than copying them over), and I *would* like them thumbnailed.
And, in another comparasion, if I do a recursive find then it *does*
follow the symlinks.  Maybe a good distinction is "Possibly destructive
behavior works only on the link itself, otherwise follow it"?

On Sun, May 04, 2003 at 06:50:56PM -0500, Mosfet wrote:
> Not really. I actually think it would be the proper behavior. Lots of 
> utilities don't follow symlinked directories.
> 
> For example, I have /usr/share/doc symlinked in /home/mosfet/Desktop so I have 
> easy one-click Konq access to my system documentation. If I rm -r my home 
> directory it certainly doesn't follow the symlink and trash /usr/share/doc 
> ;-) I don't think I'd expect a thumbnail generation utility to follow it 
> either. It would be unexpected behavior for:
> 
> mkthumb /home/mosfet
> 
> to go thumbnailling /usr/share/doc as well >:) 
> 
> On Sunday 04 May 2003 02:58 pm, Esben Mose Hansen wrote:
> > On Sunday 04 May 2003 20:22, Mosfet wrote:
> > > I mean it's okay in that it works, I just don't know if users will demand
> > > symbolic links to folders be followed or not ;-)
> > >
> > > My current implementation uses lstat, which will cause symbolic links to
> > > not be recognized in S_ISDIR(), so the link is never added into the list
> > > of folders to process.
> >
> > Ignoring symlinked directories would be a surprising behaviour from a
> > program, I'm afraid :-/ Perhaps you could insert the inode number in your
> > list and skip any directories whose inodes was already in there? It would
> > probably be worth it to keep this list sorted. The "right" implementation
> > would be a hash of list, of course, but that's probably not worth the
> > bother unless you have such a hash implementation lying around.
>  
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]