From: Moi on
On Sat, 30 Jan 2010 00:23:07 -0700, frank wrote:

> Moi wrote:
>> On Wed, 27 Jan 2010 00:21:30 -0700, frank wrote:
>>
>>
> snip
>> 4) I compacted your process_directory() function for you.
>
> Thanks so much for tinkering with this source, Moi. It really helped me
> to see this function re-fashioned.

> So, are there any more than than these possibilities for entry.d_name:
> 1) .
> 2) ..

These are in fact just ordinary directory entries
with an exceptional role.

> 3) directory
> 4) regular file
> 5) link

Well, there are named pipes and unix-domain sockets, and
device-"special" entries. And maybe a few more I missed.

Check man 2 stat or /sys/stat.h for what st_mode can contain.

AvK

From: Moi on
On Fri, 29 Jan 2010 17:58:38 -0700, frank wrote:

> Ben Bacarisse wrote:

>
> What remains is muddling my way through unix.
>>
>> I don't know what you intend (a short description of the purpose would
>> help) but the code you posted is equivalent to a few lines of bash
>> script (or Perl or Python...). If you don't know any of these,
>> learning enough bash to do what the C code does would not take long (a
>> day or so).
>
> There are easier ways to read a directory than using C.

Yes, a "normal" unix programmer would probably just use
find . -type f | ./myprogram

, and let myprogram read the pathnames from stdin.

And there is the ftw(3) way of doing things.
But it is always good to have done these things
at least once by oneself. Not for reinventing the
square wheel, but just because it helps one understand the
(choices made for the) API's for the library functions better.

HTH,
AvK
From: Pascal J. Bourguignon on
frank <frank(a)example.invalid> writes:

> Moi wrote:
>> On Wed, 27 Jan 2010 00:21:30 -0700, frank wrote:
>>
>
> snip
>> 4) I compacted your process_directory() function for you.
>
> Thanks so much for tinkering with this source, Moi. It really helped
> me to see this function re-fashioned.
>
>> if (!strcmp (entry.d_name, ".") || !strcmp (entry.d_name, "..") ) continue;
>> namelen = strlen(entry.d_name);
>> if (dirlen+1+namelen+1 >= sizeof pathName) {
>> fprintf(stderr,"Name too long: %u+1+%u+1 %s/%s\n"
>> , (unsigned) dirlen, (unsigned) namelen,theDir,entry.d_name );
>> continue; }
>> memcpy (pathName, theDir, dirlen);
>> pathName[dirlen] = '/';
>> memcpy (pathName+dirlen+1, entry.d_name, namelen +1);
>> if (lstat (pathName, &entryInfo) == -1) { /* stat() failed,
>> let's party */
>> fprintf (stderr, "Error statting %s: %s\n", pathName, strerror (errno)); continue; }
>> count++;
>> if (S_ISDIR (entryInfo.st_mode)) { /* directory */
>> printf ("processing %s/\n", pathName);
>> count += process_directory (pathName);
>> continue; }
>> if (S_ISREG (entryInfo.st_mode)) { /* regular file */
>> printf ("\t%s has %lld bytes\n"
>> , pathName, (long long) entryInfo.st_size);
>> continue; }
>> if (S_ISLNK (entryInfo.st_mode)) { /* symbolic link */
>> char targetName[PATH_SIZE + 1];
>> if (readlink (pathName, targetName, PATH_SIZE) == -1) {
>> printf ("\t%s -> (invalid symbolic link!)\n", pathName);
>> continue; }
>> printf ("\t%s -> %s\n", pathName, targetName);
>
> So, are there any more than than these possibilities for entry.d_name:
> 1) .
> 2) ..
> 3) directory
> 4) regular file
> 5) link
> ?

NAME_MAX
Yes. There are about Σ 254^i - 5 other possibilities for entry.d_name.
1

(all the byte values are possible in d_name, but 0 and 47, and d_name
may be any length from 1 to NAME_MAX).


On my system, where NAME_MAX is 255, that makes:

17151848561775
524542260230899909345527623287683809220880277204575135673770
350790616073358738754853669771246761598037707765815012818953
935481259985629589001894465990514560016269745315761470342905
916427583379787162454198607651001112150892505697618658680722
340651617534533646250823154025408246347525049252624268535973
202331185548752849740059467645750723512718885190900684145962
332212188080108626733451568195673134215363122237241696148086
390170981092766227408226801240032059729007827039773745754612
965254102893844749238702970926320276892692441496131912435884
815683131626478581446738498427741257604636279796430784947109

other possible values.



Now, if you're asking about st_mode, in addition to directory, regular
file, and symbolic link, there are at least named pipes, sockets,
character device, block devices. Perhaps some more.


Notice that . and .. are directories, and that hard links are not
distinguished from other directory entries (only that modern file
systems prevent you to make hard links of a directory).

--
__Pascal Bourguignon__
From: frank on
Pascal J. Bourguignon wrote:
> frank <frank(a)example.invalid> writes:

>> So, are there any more than than these possibilities for entry.d_name:
>> 1) .
>> 2) ..
>> 3) directory
>> 4) regular file
>> 5) link
>> ?
>
> NAME_MAX
> Yes. There are about Σ 254^i - 5 other possibilities for entry.d_name.
> 1
>
> (all the byte values are possible in d_name, but 0 and 47, and d_name
> may be any length from 1 to NAME_MAX).
>
>
> On my system, where NAME_MAX is 255, that makes:
>
> 17151848561775
> 524542260230899909345527623287683809220880277204575135673770
> 350790616073358738754853669771246761598037707765815012818953
> 935481259985629589001894465990514560016269745315761470342905
> 916427583379787162454198607651001112150892505697618658680722
> 340651617534533646250823154025408246347525049252624268535973
> 202331185548752849740059467645750723512718885190900684145962
> 332212188080108626733451568195673134215363122237241696148086
> 390170981092766227408226801240032059729007827039773745754612
> 965254102893844749238702970926320276892692441496131912435884
> 815683131626478581446738498427741257604636279796430784947109

Thx, Pascal, I think I've got enough fingers and toes to count out the
possibilities there. :)

I wouldn't mind seeing the source for this calculation. I took applied
combinatorics with problem solving, but the professor was of a more
theoretical bent. (I'm not complaining, Dr. Goldman is quite brilliant
but he is proud that the only "computing" he's done was written cards
for a Turing machine in grad school before the advent of the microcomputer.)

How would '...' be interpreted by stat?
--
frank
--
From: Pascal J. Bourguignon on
frank <frank(a)example.invalid> writes:

> Pascal J. Bourguignon wrote:
>> frank <frank(a)example.invalid> writes:
>>> So, are there any more than than these possibilities for entry.d_name:
>>> 1) .
>>> 2) ..
>>> 3) directory
>>> 4) regular file
>>> 5) link
>>> ?
>> NAME_MAX
>> Yes. There are about Σ 254^i - 5 other possibilities for entry.d_name.
>> 1
>> (all the byte values are possible in d_name, but 0 and 47, and
>> d_name
>> may be any length from 1 to NAME_MAX).
>> On my system, where NAME_MAX is 255, that makes:
>> 17151848561775
>> 524542260230899909345527623287683809220880277204575135673770
>> 350790616073358738754853669771246761598037707765815012818953
>> 935481259985629589001894465990514560016269745315761470342905
>> 916427583379787162454198607651001112150892505697618658680722
>> 340651617534533646250823154025408246347525049252624268535973
>> 202331185548752849740059467645750723512718885190900684145962
>> 332212188080108626733451568195673134215363122237241696148086
>> 390170981092766227408226801240032059729007827039773745754612
>> 965254102893844749238702970926320276892692441496131912435884
>> 815683131626478581446738498427741257604636279796430784947109
>
> Thx, Pascal, I think I've got enough fingers and toes to count out the
> possibilities there. :)
>
> I wouldn't mind seeing the source for this calculation.

NAME_MAX
The source is: Σ 254^i - 5
i=1

The compiled form is: (- (loop for i from 1 to 255 sum (expt 254 i)) 5)


> How would '...' be interpreted by stat?

stat(2) doesn't interpret anything, and "..." is a perfectly valid
name for any directory entry.

[pjb(a)galatea :0.0 tmp]$ touch ...
[pjb(a)galatea :0.0 tmp]$ ls -l ...
-rw-r--r-- 1 pjb wheel 0 Jan 31 01:21 ...
[pjb(a)galatea :0.0 tmp]$ rm ...
[pjb(a)galatea :0.0 tmp]$ sudo mknod ... b 1 2
Password:
[pjb(a)galatea :0.0 tmp]$ ls -l ...
brw-r--r-- 1 root wheel 1, 2 Jan 31 01:22 ...
[pjb(a)galatea :0.0 tmp]$ sudo rm ...
[pjb(a)galatea :0.0 tmp]$ # etc



--
__Pascal Bourguignon__
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Reading /proc/<pid>/maps
Next: Code and Creation 73169