Non-comma delimiters not supported (leading to errors like "no email")

even i getting same issue specially for those user which are created by facebook or by twitter or by open id

Not sure what you mean by "no email" error.

Can you describe what you see on the form where you set up the import?

Are the csv file columns displayed as rows that can be matched to Drupal fields?

I am having the same problem, all fields in the file are found, and can be matched to profile fields. Everything looks fine, after importing the message says "Imported", but all lines in the csv file give a "no email" error in the import list, and none of the other fields are showing any values.
Using drupal commons.

We also experienced this issue. From what I can see, this may be related to problems with delimiters. When using a semicolon delimiter it seems that the fields are not being parsed correctly (only the first field in each row seems to pass data for processing to user_user_import_data()), and so the required "email" field may be interpreted as empty, thus triggering this error. When switching to a normal comma delimited structure (instead of semicolon) the "no email" problem went away.

This is pretty preliminary, but maybe it's info that will help someone. I can't be too sure as to the specific source of the problem, but I do suspect it's related to the handling of delimiters.

I think this is actually a bug report, but as I have not yet checked for this error in dev, I'll leave the issue marked as "support request" for now.

Ok, this really seems to be a bug. I just grabbed the most recent code from git and the problem persists. From what I can see, though the admin interfaces work with custom (non-comma) delimiters, but the actual import process does not. I'll see if I can make a patch for this as I think I found the specific spot in the code where this plays out.

Btw, the head of the 6.x-2.x branch is tagged as 6.x-4.1.... that's a bit confusing. I'm not sure if this should be marked as 6.x-2.x-dev or 6.x-4.1?

So for some reason the actual import processing methods don't have any support for a custom delimiter. In fact, it seems that a comma is hard-coded into these methods. For example, see line 28 of user_import.import.inc which is:

while ($data = fgetcsv($handle, $line_max, ',')) {

This makes the custom delimiter settings irrelevant.

The attached patch attempts to address this. This a git formatted patch that could be applied to the head of the 6.x-2.x branch and to 6.x-4.1 (as both appear to be equivalent).

I just wanted to check-in and see if anyone else has had a chance to test this patch. I don't think this is a "major" bug, but given the general popularity of this module I imagine it could cause lots of confusion (after all, the configuration options do support a custom delimiter setting).

Even without a review it might be worth one of the maintainers having a quick look as I think the patch represents a fairly innocuous change.

Thanks!

Fixed in 6.x-4.2 and next 7.x-1.0-beta2 (once it's released).