Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#3262 closed Bug (fixed)

problems with "." as first char in torrent names.

Reported by: Astara Owned by: charles
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.90
Severity: Normal Keywords: backport-1.9x
Cc:

Description

I've run into a problem maintaining a torrent I downloaded with utorrent. It starts with a "." character. Problems I've noticed after transferring it to transmission 1) transmission wouldn't pick it up from the watch directory. (I didn't know why at the time, so I started it by adding it via one of the gui's, which worked.

2) if I have to restart transmission, it doesn't restart that torrent -- this seems to have gotten worse since 1.93 -- as I thought it used to restart, but I may be imagining things. Anyway, I do know that now, if the ".resume" file starts with a "." (i.e. torrent saves the resume file as ".foobar.torrent", it won't restart it after having saved it with a "."!

Clearly this is undesirable behavior. While "." may be used to "hide" config files from users during interactive use, it should not hide .torrent files, and *especially* should not hide transmission's own data files (.resume) from itself!

Attachments (4)

dotfiles.diff (3.4 KB) - added by charles 11 years ago.
possible fix; ready for testing
dotpatch.diff (7.8 KB) - added by Astara 11 years ago.
revised dotpatch...missing some changes in session.c
dotfiles.r2.diff (5.3 KB) - added by charles 11 years ago.
diffs to r1: add ".torrent" suffix check to metainfoLookupInit(). As per Astara's patch, skip only dot and dotdot when walking directories in walkLocalData(). Do the same in moveFiles().
dotpatch.2.diff (7.4 KB) - added by Astara 11 years ago.
tr_null_or_dotsys_dir cleanup; some spurious code changes elided

Download all attachments as: .zip

Change History (31)

comment:1 Changed 11 years ago by charles

Another point to this issue: Longinus00 has pointed out that the GTK+ and Qt clients already process dotfile torrents in the watchdir.

Changed 11 years ago by charles

possible fix; ready for testing

Changed 11 years ago by Astara

revised dotpatch...missing some changes in session.c

comment:2 Changed 11 years ago by Astara

I tested my file against my problem, and it fixed the problem, but that doesn't verify that it fixed everything. Specifically my test worked without anything being fixed in session.c. I had a ready routing to pop in though so that was a quick add.

I added code that was equivalent to what what the comments said the code was doing. Any place where the comments said it was skipping "." and "..", I added call to a routine to check for those two entries. (. followed by \000, OR ".."followed by a \000"). So every place where there wasn't a check for ".torrent" immediately after, I presumed wanted still wanted to check for and ignore "." and "..".

There was also a check in metainfo.c. for "the characters". I made it, as well only ignore the two system directory entries.

This seems like it should be a patch that only fixes the problem while being sure to still ignore the system dirs where needed.

It _adds_ no presumptions about the extension (i.e. those that were there before still are, anyplace where .torrent wasn't checked for as an extension still is not checked).

I don't know if you found places where it should have been checked or not. If that's the case, then this patch doesn't address that bug.

Perhaps it would belong under another bug? (if your patch addresses such issues...I wasn't sure, but looking at it, but it seemed to?)....

This patch should apply against the stated version of the source tree...

if there is a problem with this this code's functionality, could you let me know?

other wise I think I'd be wasting my time when when I thought we had agreement that since I was filing the bug (and had the problem), I'd go ahead and submit the patch?

caio

Last edited 11 years ago by Astara (previous) (diff)

comment:3 Changed 11 years ago by charles

I don't have any major complaints with this patch, but several minor ones. Since you're likely going to be submitting more patches I'll go through the list here:

  • in torrent.c, vim indentation notes
  • in utils.c, a gcc pragma to disable a warning instead of just adding the parenthesis. gcc isn't the only compiler in the world.
  • in utils.[ch], the arg should probably be a const char * rather than a const char []
  • in torrent.c, watch.c and utils.h, arbitrary formatting changes
  • in metainfo.c, I'm not convinced that dotfiles should be added to the torrent's metadata's list of files. That seems like a recipe for future problems.
  • in utils.h, public API funcs should have a Transmission namespace -- in C, by prefixing the function name with "tr_"
  • in utils.c, not_dot_or_dotdot_dir() will crash when fed NULL
  • the return type for funcs that return zero for false and nonzero for true should be tr_bool
Last edited 11 years ago by charles (previous) (diff)

Changed 11 years ago by charles

diffs to r1: add ".torrent" suffix check to metainfoLookupInit(). As per Astara's patch, skip only dot and dotdot when walking directories in walkLocalData(). Do the same in moveFiles().

comment:4 follow-up: Changed 11 years ago by Astara

in response to your comments 1) Regarding: in torrent.c, a 2 line comment at bottom, with default vim settings so vim will keep file's settings (no tabs but use spaces instead of tabs, and set tab stops to 4 columns instead of system default 8) -- are you saying you don't want someone using vim to keep the file's current settings? Does the comment affect program performance or execution? ;-)

2) I'm all for disabling the warning entirely at compile time. It's a pretty stupid warning saying "I don't think you are an intelligent C programmer, so please program at the 3rd grade level and add lots of parens, rather than relying on stated language features." If you want to disable it globally in the makefile. I'm willing to add that change. I don't like adding crappy workarounds for compiler warnings about things that are NOT errors.

OR, people running with different compilers may not get that warning at all -- in which case the pragma's can be moved a column to the right -- where, from what I read, standard C will ignore it as a preprocessor statement and give no warnings in any regard. I thought I had it that way, but moved it to the column one due to some testing/build problems -- then forgot to move it back.

OR, a differnt compiler can use a different pragma perhaps. I really don't like writing looking code to get around compiler bugs...so why don't we turn that one off.

Specicalling, it didn't like "C's ability to short-circuit execution in a logical statement

that uses && and
. -- and for some reason though that && and caused confusion. I don't

see why.... I used parens where needed.

  1. in utils.[ch]: arg being const char [] v. const char *: "Why"? IT is used as

arg[0] arg[1] arg[2], not *arg *(arg+1) *(arg+2). The argument should be consistent with usage. If you want to change the const char *. Then usage should be change to *arg *(arg+1)...etc which I think is less clear -- and is certain a change from how it was implemented before I came along. Thus it wasn't a part of this change set. Can you tell me why you think the change set should be incompatible with the existing code?

  1. arbitrary formatting changes --? out side of my code? ... I tried to restrain myself.

Honest. hmmm.... I didnt? Would have to look...code format is pretty broken /buggy... It's pretty bad from a C-code standpiont. Looks like someone wrote it who was mroe fluent in some other language, but there are some grave C no-no's committed. While others are less severe and merely lower the problem solving speed of anyone looking at the code and possible lower the overall ability of them to solve complex problems in the code, but such effects would be minor, but consistent with known physiological reading studies. But for example -- BAD practice -- formatting C-statements like functions. That is just bad and misleading programing style. "if( true )" instead of "if (true)'.

The C-language terms are not functions. if any operators deserve spaces around them (and not all do), but if ANy do -- C-language keywords do so most definitively! Other issues...parens are not meant to be decorative. They are meant to group what is in side them -- thus they should cuddle up next to their content -- especially at the 1st outer level. Inner parens should be cuddled 'mostly', but spaces can be inserted for readability. Blindly inserting spaces everywhere hinders reading comprehension and makes the code less clear.

Issue like that and curly brackets that follow a control word being on the same line as their control word -- speed and aid comprehension. Curly brackets that are *part* of a control-word sequence, shouldn't be split up over multiple lines -- because the curly bracket is *part* of the control word sequence. like 'if' has the syntax:

if <conditional> <statement>, where conditional=<openparen>expr<close paren>, and

statement=simple, "1-liner" |OR| a multiline statement enclosed by brackets. if statement is short, then putting it on the same line can aid code readability. like if (cond) continue; OR "if (cont) return false;" in the same way, the opening bracket, being 1 required term part of the if statement, can always and should be on the same line as it's opening statement. If you need to put it on the next statement, standard is to indent the next line by 'indent' value (or more) to indicated it is a continued line from the previous line. But turning a control statement into a 2-line affair unecessarily adds a bunch of veritcal space and causes fewer lines to fit on the screen.

This causes less procedure to fit on the screen in one-view -- and makes it harder to see

what is going on in 1 glance. Linus has made the same statement. In fact all of the issues I have are differences from the linux kernel standard -- EXCEPT for the tab stops. I think 8 spaces per tab causes the same problem horizontally as other things cause vertically. I prefer using 2-3 spaces/tab, but am willing to use 4 spaces / tab to conform to current code formatting. It's just that it looks a bit excessive. But I can tolerate that.

Does that answer that question and perhaps a bit more?

  1. I am convinced that transmission shouldn't make presumptions about file names inconsistent with other programs like utorrent or I'd bet, bitorrent. It makes transmission stand out as incompatible and that has caused problems. It's a bad design philosophy to design in arbitrary differences. I believe transmission should behave like a normal bit torrent client and not pick special things to ignore that ARE NOT normally ignored -- "tar" doesn't ignore . files when you package up a directory. It may have a switch to *ignore* such files, but the default is to pick up everything. I wouldn't be against a switch to ignore things like .rcs or the such...but it should be an additional feature. Not the default. If this is what you want, please file it as an rfe, but please do not break the patch in providing standard functionality.
  1. fine. no issue.
  1. Not exactly, but it will cause the next statement to fail. It checks for null

pointer itself on the first 'if (ptr), which if false, will, due to the logic of this statwment cause it to return 'true' and cause bad things to happen' I wondered about the logic as I reused the function in 'session.c' with a "!not..."... better would be to make the logic not negative then that problem wouldn't happen.

  1. no issue.

How do you want to handle what?

:-)

comment:5 in reply to: ↑ 4 Changed 11 years ago by charles

Since arguing these points is probably no more your idea of a nice Saturday morning than it is mine, I've tried keep these responses concise for you. :)

  • Neither KTorrent nor Deluge add dotfiles when creating torrents and Transmission shouldn't either. uTorrent and BitTorrent? (which are the same application) are moot because Windows has different filename idioms.
  • Adding the parenthesis arguably adds readability for future contributors. It unarguably is simpler and faster than any of the suggested alternatives. It's the best solution.
  • const char * is universally used in API functions that take a string, as can be seen in /usr/include/string.h or literally any other /usr/include header. In terms of function arguments, char[] is degenerated into char* at the compiler level, which is why the patch succeeds. I have never seen production code use *(str+1) vs str[1] based on the function's argument list in the way you describe.
  • This isn't the first time we've discussed code formatting, and you've ignored my request to submit patches in the existing formatting style. There doesn't seem to be any productive reason to continue this one topic. The current formatting scheme has existed for literally years and has not deterred other contributors. You need to decide for yourself if this is a dealbreaker for you.
Last edited 11 years ago by charles (previous) (diff)

comment:6 Changed 11 years ago by charles

Moreover:

#include <stdio.h>

static int
not_dot_or_dotdot_dir( const char p[] )
{
    printf( "in not_dot_or_dotdot_dir with \"%s\"\n", (p?p:"(Null)") ); 
    const int i = p && p[0] !='.' && p[0]  || ( p[1] !='.' && p[1] )  ||  p[2]; 
    printf( "returning %d\n", i );
    return i;
} 

int
main( void )
{
    not_dot_or_dotdot_dir( ".." );
    not_dot_or_dotdot_dir( "." );
    not_dot_or_dotdot_dir( "foo" );
    not_dot_or_dotdot_dir( NULL );
    return 0;
}

yields this output:

in not_dot_or_dotdot_dir with ".."
returning 0
in not_dot_or_dotdot_dir with "."
returning 1
in not_dot_or_dotdot_dir with "foo"
returning 1
in not_dot_or_dotdot_dir with "(Null)"
Segmentation fault (core dumped)

The code is incorrectly returning nonzero for "." and is crashing on NULL.

comment:7 Changed 11 years ago by Astara

mentioned that logic need to be reversed and the tests negated ... using the reverse/revised function (renamed for different functionality)

int null_or_dotsys_dir(char * p) {
    !p || !(*p) ||  
        (*p == '.' &&  
            (*(p+1)==0 || (*(p+1)=='.' && *(p+2)==0)));

}

I you want to beef up your test suite, including all the relevant test cases is good:

null_or_dotsys_dir(0); null_or_dotsys_dir(""); null_or_dotsys_dir("."); null_or_dotsys_dir(".."); null_or_dotsys_dir(".a"); null_or_dotsys_dir("..a"); null_or_dotsys_dir("a.a");

originally, I, obviously, only tested the case I said I tested -- i.e. the torrent that was broken.

Last edited 11 years ago by Astara (previous) (diff)

comment:8 Changed 11 years ago by charles

the revised function generates two warnings:

foo.c:4: warning: statement with no effect
foo.c:8: warning: no return statement in function returning non-void

looks like an easy fix, prepending a "return "... not a problem.

Changed 11 years ago by Astara

tr_null_or_dotsys_dir cleanup; some spurious code changes elided

comment:9 follow-up: Changed 11 years ago by Astara

It wasn't in my tree... resubmitted diff from my tree...should look similar to previous patch -- with fix for the function logic change & name changed adding 'tr_', returning type tr_bool, proto const char *.... as noted in example above, code changed to use *p rather than p[x] in accordance w/desired prototype.

I think I removed most or all spurious code changes outside of my changes. I think I left a line split or two in where lines ran off beyond 80 columns;

As for code format changes, I'm not willing to stop making modifications based on the pre-existing poor coding practices. But I will continue to try to educate and push for growth.

A quote comes to mind... “The reasonable man adapts himself to the world – the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man”. - George Bernard Shaw

*cheers*


In regards to session ignoring "." files...I can understand your point of view, but I would like to see it controlled with a user-modifiable setting (perhaps the json file? for the nonce) "ignore-dot-files-during-session-creation" with it defaulting to true on the linux platform. That way it doesn't leave users stuck with no way to get around unwanted behavior, nor saddle other platforms that might not have the same conventions with this old unix convention".

Feel free to ignore portions of my patch affecting those files for the time being until that option can be added? Unless you want to toss it in...I don't know now to do options yet. ;-)

Last edited 11 years ago by Astara (previous) (diff)

comment:10 in reply to: ↑ 9 ; follow-up: Changed 11 years ago by charles

Replying to Astara:

think I removed most or all spurious code changes outside of my changes.

...inside your changes, however, you continue to ignore the project's use of whitespace.

As for code format changes, I'm not willing to stop making modifications based on the pre-existing poor coding practices. But I will continue to try to educate and push for growth.

I'm tired of arguing minutiae with you. We could continue this game if your patches were worth the cost, but the "problem" being solved is one which nobody else has reported in four years and whose proposed solution is a trivial one-liner which required three iterations to get right, which is still difficult to read, and which is still an overspecialized function shoehorned into a generic utilities toolbox. That payoff is simply not worth the the cost of continuing to read about how Transmission should turn off certain GCC warnings to suit you, how Transmission's whitespace style should be changed to suit you, how the developers should move from IRC to email to suit you, whether a ticket for a missing feature should be tagged as a bug or enhancement, whether or not fansubs are legal, and on, and on, and on.

If you will not or can not improve your S/N ratio, please find a different BitTorrent? client to volunteer for. There are several actively-developed BitTorrent? projects to choose from.

In regards to session ignoring "." files...I can understand your point of view, but I would like to see it controlled with a user-modifiable setting (perhaps the json file? for the nonce)

No. You have given no reason at all -- much less a compelling one -- why Transmission should behave differently from KTorrent and Deluge in this regard.

comment:11 Changed 11 years ago by charles

fixed in trunk for 2.00 w/dotfiles.r2.diff by r10736

comment:12 Changed 11 years ago by charles

  • Keywords backport-1.9x added
  • Owner set to charles
  • Status changed from new to assigned
  • Version changed from 1.93+ to 1.90

comment:13 Changed 11 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:14 in reply to: ↑ 10 ; follow-up: Changed 11 years ago by Astara

response to comment#8: inside your changes, however, you continue to ignore the project's use of whitespace.

I'm tired of arguing minutiae with you.

--- First, let's clarify terminology. When you say "project", you mean "your". The project isn't a physical object with defined attributes, a synthetic object with attributes defined by it's owners. You are the owner. The white space attribute is your convention. So the above would more accurate read "you continue to ignore my [preference for] use of whitespace".

Second, when you say "whitespace", you mean a "minutia". But you also claim you are tired of arguing such. Then stop and let it go. If it's not important to you, then consider it might be important to someone else. If it's not important to you, what's the cost of allowing someone else to do change it to something suitable to a different format? It's a one-time code check-in. You go on. End of story. And the problem with this is? It's really quite painless.

We could continue this game

--- That you consider adequate testing against standards to be a game reflects on the stage of the project.

if your patches were worth the cost,

--- And the cost is? Ignoring or ceding [resign, grant] items or issues you have described as minutiae?

but the "problem" being solved is one which nobody else has reported in four years

--- That no example has been proposed for four years is merely a function of exposure and usage. Until code has been exposed to new test cases, it can't be expected to know about them. However, it seems that you are using the code's previous inexposure as reasoning that it was "just fine the way it was". Code should be robust and future-proofed when practical.

and whose proposed solution is a trivial one-liner[sic]

A simple 'grep + wc' of the patch on "\+" shows 66 lines inserted. 66!=1 Please don't misrepresent the facts in a way that misrepresents truth. Simple, yes, 1-line, no.

which required three[sic] iterations to get right,

I see two patches submitted by me. You are counting my comment as a patch I take it? You presumed that adding 'return' would make that routine work? It wasn't intended as code but as the formula for your test case in #3262#comment6. The solution you present in comment #8 wouldn't make it work in the code as the boolean sense of the routine had been inverted consistent with #3262#comment4 subsection 7. The full patch which was later submitted, was the second iteration of the code.

which is still difficult to read, and which is still an overspecialized function shoehorned into a generic utilities toolbox.

--- utils.c isn't documented to be a generic utilities toolbox. It's name indicated it to be a repository for utility functions common to more than one module There is nothing to indicate it's supposed to be a generic toolbox as you presently assert. Other consistent, non-generic routines: . tr_deepLoggingIsActive . tr_deepLog

If there is a more appropriate place, I'm unaware of it. Do you have an alternate location suggestion? I've no stronger opinions about where it should go other than what I've stated. Is utils.c isn't a place to hold common util functions, what module is?

As for difficult to read. That depends on the background of the reader:

  /* let 'EOS' = end of 'C' string */

  !p || !(*p) ||        /* if null or EOS */
      (*p == '.' && (       /* if p[0]== .  AND either  */
          *(p+1)==0             /* p[1]==EOS  (ie. string=".") */ 
	    || 			          /*  OR  */
              /* case of  ''p[0-2]=='.','.','\000' ''  or  ''string=".."'' */
	      (*(p+1)=='.' && *(p+2)==0)
	    )
	);

That payoff is simply not worth the the cost of continuing to read about how Transmission should turn off certain GCC warnings to suit you, how Transmission's whitespace style should be changed to suit you, how the developers should move from IRC to email to suit you, whether a ticket for a missing feature should be tagged as a bug or enhancement, whether or not fansubs are legal, and on, and on, and on.

Then your response devolves into statments based on partial and misleading truths. As such, they are not worth further comment, with the exception of of your last statement is being a example of your misleading word style.

You have given no reason at all -- much less a compelling one -- why Transmission should behave differently from KTorrent and Deluge in this regard.

--- In comment#10, I gave 2 reasons:

  1. it doesn't leave users stuck with no way to get around unwanted behavior" (namely, it ignoring certain files in a directory, when this behavior may not be wnted)
  2. [it doesn't] saddle other platforms that might not have the same conventions with this old unix convention

I haven't tried ktorrent, but deluge was rough around the edges. I wouldn't think new or immature products would handle details like '.files' in any regard. As for why transmission should be more mature? Because it should be better.

comment:15 Changed 11 years ago by charles

What is your goal in continuing this?

comment:16 Changed 11 years ago by Astara

Was just trying to answer some of your points. I feel you either misunderstood or were misrepresenting some things. I don't have the energy to continue this right now as I have other more pressing things to take care of. But should I find more energy to focus on things in transmission, I wanted you to better understand how I felt.

comment:17 in reply to: ↑ 14 ; follow-up: Changed 11 years ago by livings124

Replying to Astara:

response to comment#8: inside your changes, however, you continue to ignore the project's use of whitespace.

I'm tired of arguing minutiae with you.

--- First, let's clarify terminology. When you say "project", you mean "your". The project isn't a physical object with defined attributes, a synthetic object with attributes defined by it's owners. You are the owner. The white space attribute is your convention. So the above would more accurate read "you continue to ignore my [preference for] use of whitespace".

Second, when you say "whitespace", you mean a "minutia". But you also claim you are tired of arguing such. Then stop and let it go. If it's not important to you, then consider it might be important to someone else. If it's not important to you, what's the cost of allowing someone else to do change it to something suitable to a different format? It's a one-time code check-in. You go on. End of story. And the problem with this is? It's really quite painless.

What's your problem? Follow the project's use of whitespace and formatting. This is something trivial to do - do it!

We could continue this game

--- That you consider adequate testing against standards to be a game reflects on the stage of the project.

This game of you ignoring our formatting, complaining about how we don't have an email list, and all the other garbage you make us sort through. Stop playing games.

if your patches were worth the cost,

--- And the cost is? Ignoring or ceding [resign, grant] items or issues you have described as minutiae?

The cost is dealing with you.

but the "problem" being solved is one which nobody else has reported in four years

--- That no example has been proposed for four years is merely a function of exposure and usage. Until code has been exposed to new test cases, it can't be expected to know about them. However, it seems that you are using the code's previous inexposure as reasoning that it was "just fine the way it was". Code should be robust and future-proofed when practical.

Getting this problem fixed is not worth it when the cost is dealing with you acting like a control freak and an asshole.

So in summary, we appreciate patches, but it's not worth it when the person comes in, ignores all existing policies about keeping the source code formatting consistent, complains about how their isp blocks our site (how is that our fault), and bitches that they don't like irc rooms and wants email lists (which none of the current devs want to deal with). If you're going to act like an self-centered egomaniac then we'd rather not put up with you and keep the small bugs. So get your head on straight, realize this isn't yours and your only, grow up, and come help us improve the project like a mature adult.

comment:18 in reply to: ↑ 17 ; follow-up: Changed 11 years ago by Astara

What's your problem? Follow the project's use of whitespace and formatting. This is something trivial to do - do it!

You are the one who keeps calling it trivial. That has never been my term. In response to this observation, I said: ""If it's not important to you, then consider it might be important to someone else. If it's not important to you, what's the cost of allowing someone else to do change it to something suitable to a different format? It's a one-time code check-in. You go on. End of story. And the problem with this is? It's really quite painless.""

We could continue this game

---

That you consider adequate testing against standards to be a game reflects on the stage of the project.

This game of you ignoring our formatting, complaining about how we don't have an email list...

--- I don't consider these or other things I have raised to be games. That you consider them to be games reflects on the stage of this project. Show me any large project that doesn't have an email list -- and USUALLY -- multiple email lists. They just don't exist on linux or unix platforms -- the only ones that get by with forums and wikis are those that 1) are too small (extensions or addons), or 2) those who are usually from the windows world offering commercial products where they don't really care about what their users say. Forums can be ignore. irc is worse than ignorable, it's hard to use, is not easily classifiable or indexable. You can't look up a thread by topic the way you can with email. You are losing valuable project history and input by doing things in irc and making it impossible to archive index or follow conversations that can happen over days or weeks. That you whine and stomp claiming that standard practices are my ego-maniacal invention only bespeaks of your lack of experience -- which I wouldn't care about if it didn't get in the way and you were willing to take input -- which you definitely have shown very poor results in. I've seen enough other inputs in the bug data base where suggests were made and you shut them out with no discussion -- unilaterally and often, IMO, rudely. That's poor project management or leadership skills.

You don't show leadership skills at all -- you show only the action of dictating your standards. You keep using the term "we" -- I've heard no one express an opinion other than your own. When I asked about an issue -- where I differed from you -- the other person wouldn't give me there opinion, but simply gave me the party line of 'deferring to you'. They didn't have the independent thought to even say "I think XXYZ" -- where it _still_ might be the exact same as your opinion, but they don't want to say something -- very likely out of concern it might be different from what you have said. From the bug database, I can see that I'm not the only one you have been short or intolerant with. You know you are right, and if someone has a different opinion, they are in for major pain every step of the way. Just to to hash out on logical grammar for command line options took over 2 hours for 6 characters of commands.

As for the code formatting, it's both a practical consideration in light of standard C programming style in use in other projects -- most visibly the linux kernel. I'm quite willing to accept your use of 4spaces/tab (vs. kernel 8/tab), but the rest of those guidelines make alot of sense if you read them. There are various resources to describe this, but probably the best would be 'the horses mouth' -- pick up the latest copy of the kernel source (or probably any version in the past several years...not sure when the file was added). under 'Documentation', file 'CodingStyle?', or http://lxr.linux.no/#linux+v2.6.34/Documentation/CodingStyle, will retrieve a recent version.

It's very close to the standard I always use -- with the difference that I usually indent less than 8 spaces. The kernel code could be cleaner in some places if it did similar, since when indenting several levels, long lines are broken at <80 columns so as not to cause wrapping.

Other notes -- I don't mind 'long names', nor do I mind mixed-case names -- Linus tends toward being more pedantic than I am. (If you want to get some experience -- go work on the kernel for a year or so...then come back and manage a project -- your view will change). Linus also has unreasonable biases against MS -- though he has mellowed in recent years. I don't mind macro names of non-upper case if they function transparently as functions or if it improves readability.

MOST of transmission is VERY readable (standard space excepted -- it hinders readability -- honest -- I can show you studies that show how extra spacing hurts reading comprehension -- and regular spacing as is used hurts the ability to focus on what's important in a way that the code is structure). I was impressed by the readability of the code I found -- especially in light of there begin no comments (I'm not big on comments either -- the code _should_ speak for itself, unless you are doing something "not straightforward" for an optimization sake).

Reading these guidelines, I see that my including "vim lines" would get rejected. Bad me! Yes, I make mistakes and am willing to admit it!

ON A PERSONAL level -- the existing space practice is very distracting. It makes it hard to see what spaces line up with what without counting (or without an editor that auto-matches them). I find the braces after their control lines distracting because it's an empty line with no purpose. I expect to see definitions there. Not a blank line. It takes up valuable screen real estate when I want to view a procedure on a page. I have enough things distracting me without seeing non-useful spaces sprinked at regular intervals through the code. It would be like reading

 a  s e n t e n c e   w i t h   a n   e x t r a   s p a c e   b e t w e e n   
 e a c h   w o r d   a n d   h a v i n g   a l l   t h e   l i n e s  b e   
 d o u b l e  s p a c e d .    I t   s l o w s   d o w n   r e a d i n g   
 c o m p r e h e n s i o n .

Getting this problem fixed is not worth it when the cost is dealing with you acting like a control freak and an asshole.

--- Now your just getting stupid. Control freak? I tried detente, but was harassed, like I was in grade-school about spaces around my letters. This is childrens stuff! I made a suggestion but agreed to leave existing code alone. Then when I submit patches, I'm given a heavy handed "controlling" attitidude of not complying with your wishes? Who's being the control freak? You are trying to control me by complaining about the code I submitted. I *stopped* complaining about the exisiting code and only raise the issue in defense of my existing practices.

My taking the *defensive* is not an example of an unhealthy boundary regarding control. Your attempting to exert your control over your exsiting domain AND me, is unhealty -- it is YOU who the "FREAK" label applies -- and you, who the 'dominating' label of "asshole" applies (presuming that is your meaning, as I don't really know the exact definition of an asshole other than in the context of one who is unreasonably dominating; it could just be you are using the word out of ignorance and purely for insult value, which would only hilight the maturity level of the user).

So in summary, we appreciate patches, but it's not worth it when the person comes in, ignores all existing policies about keeping the source code formatting consistent,

--- I ignored none of them. I addressed them in detail. I suggested useful ways of dealing with the problem and was told some of the suggestions (automated code-formatting/beautifiers) had been tried, but that the existing code failed all attempts at "regular formatting".

complains about how their isp blocks our site (how is that our fault),

It wasn't my ISP blocking your site. IT was the fact that your site was on a black list, I was told (by you), and that my ISP supposedly used this black list. Unfortunately, I didn't get sufficient headers from you to verify this.

and bitches that they don't like irc rooms and wants email lists (which none of the current devs want to deal with).

--- The deficiences of having no email log are noted above. I didn't request abandonment of IRD, but expanding the available communication channels.

come help us improve the project like a mature adult.

That's what I do: to help mature and grow the project. I seem to be getting alot of reistance to that -- Attempting to apply standard larger project methodologies to this project has resulted in nothing but resistance.

comment:19 Changed 11 years ago by livings124

Please find another BitTorrent? program. None of the developers wish to continue dealing with you.

comment:20 in reply to: ↑ 18 ; follow-up: Changed 11 years ago by charles

Replying to Astara:

You keep using the term "we" -- I've heard no one express an opinion other than your own.

Are you talking to me or livings here? You're responding to a comment by him, but seem to be talking to me, and don't really acknowledge him. I find this confusing.

comment:21 in reply to: ↑ 20 ; follow-ups: Changed 11 years ago by Astara

Replying to charles:

Replying to Astara:

You keep using the term "we" -- I've heard no one express an opinion other than your own.

Are you talking to me or livings here? You're responding to a comment by him, but seem to be talking to me, and don't really acknowledge him. I find this confusing.

--- At the time I wrote that I didn't realize it was a different person. Not until much later when I realize their word choice was more crude than you've used, did I question it being the same person. Then I noticed the name.

Replying to livings124:

Please find another BitTorrent?? program. None of the developers wish to continue dealing with you.

--- Who are you? I have no record of interacting with you. Charles is the only developer I know of that I've interacted with, but its possible I had some interaction on irc, briefly, -- I don't know -- it was hard to tell who was who, nevertheless, I don't think I've had any direct interactions with anyone of any import, other than here. So it's hard to see, other than by hearsay, how 'none of the developers' would wish to deal with me. It may be true, but it would be based on my not being able to interact with them directly in the first place, which is hardly a fair response. Asking you a point: are you saying that none of the current devs do any email? You say 'they' don't want to do an email list. What are you envisioning? For myself, it could be something simple, but I wanted a way to send a message to the current developers. There didn't seem to be a way to send them a message where I'd be reasonably certain they would directly receive it.

I certainly don't think it is acceptable for me to copy a message into IRC and hope that they happen to have a log running and would respond back in kind. Personally, I find it very difficult to read through and try to find messages directed to me -- but that may be partly due to the client I have or my recent inexperience.

Nevertheless, I envisions an email list with the contributing developers on this list where, I, at least, could send off a message to either ask if anyone was working on X, or had experience with X, or similar -- they could respond privately, or respond-to-all, which which send to the other developers. That's my idea of a list. How is that a problem to deal with? No one ever said anything about "lists" (plural). I'd hoped that one was available already -- I certainly didn't want to try to have to convince anyone that an email list would be a good thing -- I've never encountered a group that didn't have at least 2-3 (developers(only), users, announce). As all were archived, anyone can read past discussions, to find out what was going on, or even stay current with what developers were doing. Developer lists are, more often than not, limited to those doing (or those who have done) development. And this list is a hassle over more than regular email because? If developers prefer IRC, there would be very little volume other than my occasional postings -- which may be few to zero given the love I'm getting, but that's a side point.

I'm not trying to play games, I tend to be very straightforward, honest and will tell people things that their best friends won't. May not be pleasant, but it will be the truth as far as I know it. I try to do things the right way -- if the group doesn't, I don't go along with groups because everyone else does. I try to maintain principles even if it is unpleasant. I do try to look for common ground, and try to find win-win situations, but that's hard to do when I'm only pressed for more concessions, even after I have offered up some. That doesn't make for me wanting to make more, but neither am I given toward being petty and rescinding what I've offered out of spite. I think of that as unproductive game playing.

Cheers!

comment:22 in reply to: ↑ 21 Changed 11 years ago by livings124

Replying to livings124:

Please find another BitTorrent?? program. None of the developers wish to continue dealing with you.

--- Who are you?

The other developer of this program, that agrees with charles that you're more trouble than you're worth. You write a lot, but don't seem to comprehend that you have approached this project as if it is your own. It is not; you are not the boss. You show no respect to our existing coding practices or our existing setup. I'm sorry you cannot grasp the fact that there are others besides yourself, and those that have put in all the work up to this point do not agree with you. I hope in the future you will learn how to work with others. Please, leave.

Cheers!

Last edited 11 years ago by livings124 (previous) (diff)

comment:23 in reply to: ↑ 21 Changed 11 years ago by charles

Replying to Astara:

I'm not trying to play games

I disagree. Maybe you're serious about the topics themselves, but arguing about whitespace is still a timewaster. We could have fixed and closed several trac tickets in the time spent on this ticket.

I do try to look for common ground, and try to find win-win situations, but that's hard to do when I'm only pressed for more concessions, even after I have offered up some.

What concessions?

comment:24 Changed 11 years ago by Astara

charles wrote:

What concessions


The first thing I tried to do was forestall a problem by trying to get a set of parameters that would format the existing code back into itself -- I could format it into my format it no problem, but if I did wide changes over the code I wanted to be able to put it back into your format. But I saw places where it wasn't consistent, and felt I needed to get such a tool from you. Second reason for that tool was so if I needed to make a bunch of changes, I could use "indent" to put it into a format comfortable for me, then when done, put it back into a format comfortable for you.

That failed.

I went ahead and submitted my first patch -- in my format and tried to leave existing code alone. I think I did. -- but at same time, my Next attempt to generate common ground (not a very persuasive attempt, I'll admit). was was to submit a suggestion for a new code format in the form of a set of 'indent' parameters that I found to work on the existing code. That didn't go over too well.

Third after that I winnowed down my list to the bare necessities that really bugged me -- i.e. going from whatever I had to issues regarding brackets and parens. I dropped my preference for 2 space/tab and adopted the project's standard of 4 spaces/tab, as that was something I yield on.

I sent a document outline the reasons for the changes I wanted -- reasons based on logic and sound programming practice -- not personal opinion. I'm not trying to push a personal opinion, but sound programming practices based on maintainability and readability studies and papers and talks I gathered over the past 25 years.

That got ignored.

So my next stance was to say, 'ok', I'll leave existing code alone, but will submit my code in as close a form as I can tolerate. You are welcome to run it through a filter to make it more acceptable or accept those parts as is.

That got the nitpicking documented in this bug report.

I took steps to forestall problems as well as making concessions more than once to try to go as far as I could on my end. Your end was as rigid as day one.

I hope you remember each of these steps?

[later] -- also, in regards to email -- I offered to set it up for you and to set you up as an admin on any such list. Setup correctly such a list would auto-archive posts, keeping a project record.


as for living124 comment:

Since you have had no interactions with me -- and I've had MANY with charles, including several emails -- you gave me zero opportunity BEFORE this crisis point to talk with you civilly, or to discuss any of these issues with you.

As was told to me before by one or more random developers on IRC. "We just defer to Charles". The other team members were described as not really having strong opinions separate from Charles -- and/or they simply just deferred to him on issues such as these. Given the above factors, I find it hard to lend weight to your words -- as it's been inferred that the only opinions that are not the same as Charles's, would be my own. I can't see you would be willing to add anything independent thought to the discussion. I might have viewed you differently, had you approached me to find out what my issues were or opened a civil dialogue, but your first salvo was attacking, with labels like 'asshole' and 'control-freak'. You might want to rethink your approach and usefulness. I don't see that you have anything to add to this discussion and have most assuredly, extended it.

Last edited 11 years ago by Astara (previous) (diff)

comment:25 Changed 11 years ago by livings124

To summarize: We asked you to keep the current formatting that has been in use for years, and your "concessions" were variations of not doing that. You have done nothing to "earn" a say over changing our formatting that we have been happy with for a long time.

You also cannot get around the fact that we do not want an email list. This project has been around for years, with many contributors. Can you take a step back to look at this and see that you came here out of nowhere and essentially started demanding huge changes.

In regards to the "other developers", there are no other developers. Those were just random people on irc.

Anyway, I see at this point that any response is going to have no content but a ton of text.

comment:26 Changed 11 years ago by charles

Those aren't concessions. Every project requests that people use the existing whitespace style, and all of this has been about you coming up with ways to avoid doing that.

As an example: if you had used your 10 years of indent experience to come up with indent arguments for Transimssion, that would have been a concession. Asking me, with no experience, to do it for you, is not.

comment:27 Changed 11 years ago by Astara

Every project does not. I didn't demand that you change, nor did I demand that you form an email list.

I made suggestions and submitted code -- you demanded that I change to fit your paradigm.

I made no such demands on you.

I don't have 10 years of indent experience. I used it for the first time less than a month ago. I've used similar. It only requires a few lines to convert most code I've worked on to a regular form. Since Transmission doesn't uniformly follow a standard, the same is not possible. Most projects don't have a need for such. Most are more flexible.

Note: See TracTickets for help on using tickets.