D'après la page de manuel de lecture (2), il ne retourne que zéro lorsque EOF est atteint.
Il semble toutefois cela est inexact et qu'il peut parfois revenir à zéro, peut-être parce que le fichier est pas prêt à être Lis encore? Dois-je appeler select () pour voir si elle est prête avant de lire un fichier à partir du disque p>
Notez que nBytes est: 1445888 p>
Certains exemples de code: p>
The value returned may be less than nbyte if the number of bytes left in the file is less than nbyte, if the read() request was interrupted by a signal... If a read() is interrupted by a signal before it reads any data, it will return -1 with errno set to [EINTR]. If a read() is interrupted by a signal after it has successfully read some data, it will return the number of bytes read.
6 Réponses :
Le seul autre cas que je peux penser à lire () renvoyer 0 est si vous passez dans les nbytes comme 0; Parfois, cela peut arriver si vous passez dans la taille de quelque chose ou autre comme paramètre. Cela pourrait-il être ce qui se passe actuellement?
Si le fichier n'est pas prêt à être lu, que devraient-ils arriver sont les retours de lecture -1 et Errno est défini sur Eagain.
Je vois ... Dans ce cas, le problème est probablement quelque chose de subtil sur l'événement autour de l'appel à lire () plutôt que de l'appel lui-même ... Je serais surpris si un tel appel système commun est devenu violer l'une de ses postconditions de base. Pouvez-vous publier plus de code pour voir s'il y a quelque chose de délicat autour de cela?
Après quelques recherches, il y a des circonstances dans lesquelles il retournera 0 que vous ne penserez peut-être pas comme étant "EOF".
Pour les détails grittiseurs, voir la définition de POSIX pour lecture (): http: // opengroup.org/onlinepubs/007908775/xsh/read.html
Certains notables sont si vous le demandez à lire 0 octets - Vérifiez que vous n'en passez pas accidentellement de 0 - et de lire après la fin de la partie "écrite" du fichier (vous pouvez réellement chercher Au-delà de la fin du fichier, qui "étend" le fichier avec zéros si vous écrivez là-bas, mais jusqu'à ce que vous le fassiez, "EOF" est toujours à la fin de la partie déjà écrite).
Ma meilleure estimation est que vous entrez dans un problème de synchronisation quelque part. Quelques questions que vous devez demander sont "Comment sont écrites ces fichiers?" et "Suis-je sûr qu'ils ne sont pas de longueur zéro quand j'essaie de les lire?". Pour le second, vous pouvez essayer d'exécuter une statistique () sur le fichier avant de la lire pour voir quelle est sa taille actuelle.
Le fichier est déjà sur disque et stable et ne lue que le fichier est de 50 000 longs. Les nbytes ne sont pas nulles et nous lisons à partir du début du fichier. Calling Stat () Rapports 50k.
@Williamkf: C'est vraiment bizarre. Il semble que cela semble être un bug de noyau / de fichier de fichiers. Je ne suis même pas sûr de la meilleure façon d'isoler un cas comme celui-ci. Vous devrez peut-être appuyer sur la liste de diffusion Linux-Kernel ou la chaîne IRC. Une chose qui pourrait être la peine d'être essayée est de voir si cela se produit sur un type de système de fichiers différent.
J'ai rencontré cette ISSE en lisant de SYSFS. Je dirais que cela pourrait dépendre de la mise en œuvre du pilote que j'utilise. Mon cas est en train de définir une longueur de lecture sur 0 et lisez renvoie 0 tandis que errono == 0 .
le figuré! J'ai eu une mémoire ininitialisée en lecture (UMR) et cherchait à tort à la fin du fichier.
C'est une lecture de la mémoire non initialisée - essentiellement une valeur "aléatoire".
@ NAIVE231 UMR == la mémoire ininitialisée Lire la lecture.
@Williamkf Pouvez-vous s'il vous plaît fournir plus de détails sur la raison. Quel UMR cause ce problème?
@AmithChintaka il y a presque sept ans, donc je ne peux donc pas dire trop avec confiance. Mon souvenir est qu'il aurait pu être un UMR en code au-delà de ce qui est montré dans la réponse qui était adoptée en tant que FD.
J'ai traqué cela plusieurs fois. Étant donné que l'application ne sait pas si une FD est attachée à un fichier plat, prise sur le réseau, le tuyau, etc., un processus peut envoyer un message de longueur nulle de certaines priorités ou autres et déclencher ceci. Je prends une attente et je vois une approche, voir si EOF Sticks:
#include <errno.h>
#include <unistd.h>
#include <poll.h>
.
.
.
int eofct = 0 ;
.
.
.
do {
switch ( readcount = read( fd, buff+currentsize, bufSize )){
case -1:
if ( errno == EAGAIN || errno == EWOULDBLOCK || errno == EINTR ){
continue ;
}
perror( "read()" );
return -1 ;
case 0:
if ( eofct++ < 100 ){
poll( 0, 0, 1 );
continue ;
}
break ;
default:
eofct = 0 ;
currentsize += readcount ;
if ( NULL == ( buff = realloc( buff, currentsize + buffsz ))){
perror( "realloc()" );
return -1 ;
}
continue ;
}
} while ( readcount ); // readcount 0 break is EOF
Si ouvert ou FCNTL définit O_NONBLOCK, une lecture doit revenir 0 jusqu'à ce que des données soient prêtes.
Je viens de courir dans cette situation. Il semble que c'est très dangereux de faire quelque chose qui se comporte comme la lecture (c'est-à-dire: un io.reader in Go) retourner zéro longueur sans io.eof. Si c'est un appelant que vous n'avez pas écrit, cela peut casser; En supposant qu'il bloquerait au moins 1 octet. Mais si vous savez que l'appelant gère cela, vous pouvez le faire.
Je ne peux pas penser pourquoi il retournerait 0 quand pas chez EOF. Pouvez-vous fournir un exemple spécifique de quand cela se produit?
Il se produit dans une tentative identique d'un sur 50 000.
@ Dummy00001 J'utilise SELECT () car la FD pourrait être un tuyau et donc non disponible. Cependant, dans ce cas de défaillance, nous lisons du disque. J'ai mis à jour la question à la fin pour donner plus de détails.
Si vous lisez un nœud de Sysfs en passant
nbytes comme 0. Un pilote peut prendre 0 à 0 et ne rien retourner tandis queerrno retourne 0. Cela me trébuche pendant une heure ... Il suffit de passer une assez grandenbytes àlire .