Sorry for the late reply, been busy as anything lately and am catching up on old email.
To be honest, the more I understand what you're trying to do the more it sounds like a highly particular use-case and not something that would be used by our more general audience of users. Today I'm more inclined to support symlinked directories than files because of the headaches symlink files lead to, such as broken links, or multiple links to the same file (which, ideally, Shotwell would recognize as the same file, and not merely duplicates). Plus, the scope of the problem Shotwell is addressing -- managing thousands, even tens of thousands of photo files -- is not something I imagine file links being appropriate for most users. As far as your test, I don't know if GLib will ever stop creating FileMonitor objects (by throwing an exception). It may be that you were able to create all those but many of them were broken, that is, not actually monitoring anything. Incidentally, I believe we do monitor symlinked directories, so that won't be necessary. -- Jim On Wed, Sep 7, 2011 at 4:04 PM, Ethan <[email protected]> wrote: > On Tue, Sep 6, 2011 at 7:30 PM, Jim Nelson <[email protected]> wrote: > >> What I should've asked before was, why can't you simply create a symlink >> from your Pictures directory to the git annex directory? That would solve >> this problem right away, I think. Library monitoring should work as well. >> > > That's a good idea but the filenames would be long and ugly instead of the > symlink filenames :) > Also I'm thinking in terms of XMP sidecars. I'd want the sidecars next to > the symlinks to be used, and don't want sidecars next to the symlink targets > to be used. But I'll accept that this might be idiosyncratic to my use > case. > > I see two or three decisions to be made in regards to symlinked-file > support: > > - Should a broken symlink count as missing files? I propose that whatever > you do for symlinked directories, symlinked files should behave the same > way. (The patch I sent you will mark broken symlinks as missing but only on > startup.) > > - Should monitors be installed on symlink targets? I think it would be > best if we could but you mentioned a system limit on the number of > monitors. I did a test on my system (Ubuntu natty+oneiric, Linux kernel > 3.0.0.9) and wrote a program that opens monitors on every directory in a > directory tree. I ran it on my home directory and it stopped at 31728 -- > this is also the number of directories found by find -type "d". How do you > feel about a patch to unconditionally install monitors on symlinked files' > directories? If that turns out to cause problems, we can keep those > monitors separate and monitor them only as resources allow. > > These are the only perils and pitfalls I can think of. Do you see any I > missed? I think with these changes (and I'll hack them up if you like), > symlinks can be as robust as they can be. > > Ethan > > _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
