| Newsgroups |
gmane.comp.audio.supercollider.devel |
| Message-ID |
<CAB_zQYvm5EQEaLDcsL8Q8sFCfNjM60ebX8UQ0GGvaXdFsUaYhg@mail.gmail.com> |
This should really have an issue in the tracker.
-Brian
On Thu, Jan 11, 2018 at 8:11 PM, brian heim <[email protected]> wrote:
> > Did it really do that before?
>
> I'm really not sure, sorry. Probably not.
>
> > Thanks for the quick look at it. Not urgent -- it can definitely wait
> for 3.9.1.
>
> No problem. For now a workaround would be to config emacs so it doesn't
> create broken symlinks, or so that it creates temp files in a separate
> directory. :)
>
> -Brian
>
> On Thu, Jan 11, 2018 at 7:55 PM, <[email protected]> wrote:
>
>> ---- On Fri, 12 Jan 2018 01:00:00 +0800 <[email protected]> wrote ----
>> > I found I am able to reproduce this locally. It looks like the .#
>> file.org file is a symlink pointing to a non-existent file. This appears
>> to be normal behavior for emacs, although it can be changed.
>> >
>> > I used an option for recursive_directory_iterator that follows all
>> symlinks, and intentionally made it fail when failing to iterate on a
>> broken symlink, because this seemed like the simplest way to match behavior
>> before the rewrite.
>> > Now, I'm thinking the best thing to do might be:- don't automatically
>> recurse on symlinks- skip any dotfile immediately
>> > - try to follow symlinks, and warn (not fail) on a broken symlink
>> > That would get rid of the error and warning in your case, but still
>> retain most of the old behavior. The _one case_ where this would make a
>> difference is if you had a symlink ".dir" pointing to some "dir". Those
>> would be compiled under the current method, but not with the changes I gave
>> above. Just tested this locally to make sure.
>>
>> I think I'd be OK with that. Certainly it would be good to have a warning
>> for symlinks to nowhere.
>>
>> I had been thinking we should see that the extension is not '.sc' and
>> ignore it without an error, but if it's a broken symlink, there's no way to
>> determine whether the target was supposed to be a file or directory, so I
>> guess the warning really is necessary.
>>
>> I don't remember the old behavior (and I don't remember seeing this
>> problem before), but... what I observed yesterday is that the broken
>> symlink failed not only the symlink, but all of the symlink's siblings in
>> the same parent directory. I had ./.#cl-manual.org (the broken link) and
>> ./clLiveCode-ext.sc, and the broken link caused the '.sc' file to be
>> skipped as well. Did it really do that before? Even if so, I think that
>> behavior should change.
>>
>> It may not be necessary to skip all dotfiles. Perhaps, if the broken link
>> is a dotfile, suppress the warning.
>>
>> Thanks for the quick look at it. Not urgent -- it can definitely wait for
>> 3.9.1.
>>
>> hjh
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.birmingham.ac.uk/fa
>> cilities/ea-studios/research/supercollider/mailinglist.aspx
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
>