> never seen a file created with a newline in the filename
> (except, perhaps as a test). The newline in filename issue
And in security exploits :-) Given a newline-based format, one *must*
quote or deny newlines in filenames, not assume they're rare. (No
obvious reason not to use URL-style %
> Just because Linux lets you get away without it doesn't mean its a good idea.
Except this has nothing to do with linux - this is unix behaviour that
goes "all the way back", it's part of the process model. It's part of
what exiting *does*, so it *is* a bug in cygwin if it isn't doing the
clean
> May i suggest this be more clear, along the lines of
> "Convert a hard link to a symbolic link if on the
> destination it would have to span filesystems" Along with a
Except that's overly precise -- for example, AFS doesn't permit hard
links to span *directories* even if they're on the same vo
> gdb is supposed to be able to catch a child just after it forks but a
> few months ago that didn't work. Perhaps it does now.
follow-fork-mode is documented as only working on HP/UX 11.x...
(sigh. fond memories of the Domain/OS debugger, were you could
"set prop fork both" [or something cl
Wouldn't using detached signatures make more sense for this application?
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
> It would be pretty cool if I could be automatically cc'd on Debian bug
> reports about rsync, if the BTS supports that.
I'm pretty sure this got added in the last month or two... (type type
type google google google) Ah yes, this posting to the debian QA list:
| You can (un)subscribe to a pack
GNU Subversions is apparently now self-hosting (and is actually free,
instead of arguably free :-) If you're looking at perforce or
bitkeeper, though, also look at Accurev 3.0 (which is
free-for-free-software, in java, *fast* and has a better consistency
model...)
> Perhaps a trailing "/" instead of training "/." is supposed to work. I do
> not remember why I didn't start using it, but I am sure I would have tried
Quite possibly because you've been bitten by class cp/rcp; cp is not
idempotent, in that if you "cp -r foo bar" where foo is a dir and bar
doe
> send_files failed to open .../data1/intlmv.data/histimv.rec:
> Value too large for defined data type
Is that Solaris 8? I ask not just because you should have mentioned
this in the bug report (tsk tsk :-) but that I've seen that error and
it *didn't* have anything to do with file size (or rsy
