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
