How Does One Discover the Full Path Name of the Current Directory?

[kvnsmnsn]

I've written a piece of code that interfaces with Postgres. It needs
to write a Postgres table to disk, which it does with the <COPYcom-
mand. That command requires the absolute file name of the file being
written to. Right now I've got it hard coded to the exact location
where I want it, but that's not very portable. Is there some way in C
to retrieve the absolute path name of the current directory, so that I
could use that in my code and therefore have my code function right no
matter where it's executed? Any information on this would be greatly
appreciated.

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

[Richard Tobin]

In article <11**********************@y5g2000hsa.googlegroups. com>,
<kv******@hotmail.comwrote:

>I've written a piece of code that interfaces with Postgres. It needs
to write a Postgres table to disk, which it does with the <COPYcom-
mand. That command requires the absolute file name of the file being
written to. Right now I've got it hard coded to the exact location
where I want it, but that's not very portable. Is there some way in C
to retrieve the absolute path name of the current directory, so that I
could use that in my code and therefore have my code function right no
matter where it's executed? Any information on this would be greatly
appreciated.

There's no portable way to do this in standard C: in fact, C itself
doesn't know anything at all about directories. But all operating
systems provide a way to do it. For example, unix systems have
getcwd() ("get current working directory") which is declared in
<unistd.h>.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[kvnsmnsn]

Thanks!

[Richard Bos]

ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:

In article <11**********************@y5g2000hsa.googlegroups. com>,
<kv******@hotmail.comwrote:

Is there some way in C to retrieve the absolute path name of the
current directory,

There's no portable way to do this in standard C: in fact, C itself
doesn't know anything at all about directories. But all operating
systems provide a way to do it.

All operating systems _where this is possible in the first place_. It is
not always possible; for example, under very early versions of MS-DOS,
there was no such thing as a directory. All common modern desktop OSes
have them, but I would not be surprised at all to learn of embedded ones
that have files, but no directories, and therefore no path names,
absolute or relative.

Richard

[jacob navia]

Richard Bos a écrit :

ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:

>>In article <11**********************@y5g2000hsa.googlegroups. com>,
<kv******@hotmail.comwrote:

>>>Is there some way in C to retrieve the absolute path name of the
current directory,

>>There's no portable way to do this in standard C: in fact, C itself
doesn't know anything at all about directories. But all operating
systems provide a way to do it.

All operating systems _where this is possible in the first place_. It is
not always possible; for example, under very early versions of MS-DOS,
there was no such thing as a directory. All common modern desktop OSes
have them, but I would not be surprised at all to learn of embedded ones
that have files, but no directories, and therefore no path names,
absolute or relative.

Richard

Nobody cares about those systems. If you would have read what the
original poster wrote, you would have seen the first sentence:

"I've written a piece of code that interfaces with Postgres."

It would be astounding that Postgres runs in an embedded OS with
no directories or under "early MSDOS" isn't it?

But at each question we have to know apparently how we make the
program portable to MSDOS systems without directories, or whatever.

Living in the past is a favorite passtime of people in this group
apparently.

[Chris Dollin]

jacob navia wrote:

Richard Bos a écrit :

>ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:

>All operating systems _where this is possible in the first place_. It is
not always possible; for example, under very early versions of MS-DOS,
there was no such thing as a directory. All common modern desktop OSes
have them, but I would not be surprised at all to learn of embedded ones
that have files, but no directories, and therefore no path names,
absolute or relative.

Richard

Nobody cares about those systems.

I bet that's not true.

If you would have read what the
original poster wrote, you would have seen the first sentence:

"I've written a piece of code that interfaces with Postgres."

It would be astounding that Postgres runs in an embedded OS with
no directories or under "early MSDOS" isn't it?

Doesn't matter -- /that/ question had already been answered.

But at each question we have to know apparently how we make the
program portable to MSDOS systems without directories, or whatever.

I think you're misreading the intention of the answer.

Living in the past is a favorite passtime of people in this group
apparently.

Some people have made money from "Living in the Past". It's not to
be sneezed at.

--
"Never ask that question!" Ambassador Kosh, /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Richard Bos]

Chris Dollin <ch**********@hp.comwrote:

jacob navia wrote:

Richard Bos a écrit :

ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:

All operating systems _where this is possible in the first place_. It is
not always possible; for example, under very early versions of MS-DOS,
there was no such thing as a directory. All common modern desktop OSes
have them, but I would not be surprised at all to learn of embedded ones
that have files, but no directories, and therefore no path names,
absolute or relative.

Nobody cares about those systems.

I bet that's not true.

Well, nobody who is anybody cares: obviously, because jacob does not
care, and jacob is the only person who is anybody, and his (lack of)
experience defines the universe.

But at each question we have to know apparently how we make the
program portable to MSDOS systems without directories, or whatever.

I think you're misreading the intention of the answer.

Quite.

Living in the past is a favorite passtime of people in this group
apparently.

Some people have made money from "Living in the Past". It's not to
be sneezed at.

Jethro Tull, for example :-).

Richard

[Chris Dollin]

Richard Bos wrote:

>Some people have made money from "Living in the Past". It's not to
be sneezed at.

Jethro Tull, for example :-).

Shh. Someone might still fall into the trap.

--
"Who do you serve, and who do you trust?" /Crusade/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Richard Tobin]

In article <46****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:

>Is there some way in C to retrieve the absolute path name of the
current directory,

>There's no portable way to do this in standard C: in fact, C itself
doesn't know anything at all about directories. But all operating
systems provide a way to do it.

>All operating systems _where this is possible in the first place_. It is
not always possible; for example, under very early versions of MS-DOS,
there was no such thing as a directory.

If you're going to be pedantic, it's equally true to say that such
systems have one directory. And the operating system certainly provides
a way to find out which of the one directories you're in, using the
following code:

In fact, CP/M (and presumably early MS-DOS, though I never used it)
had one directory per disk, and there was no doubt a way to find out
what the current disk was, which would be necessary to get the
equivalent of an "absolute path name".

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[llothar]

On 11 Mai, 14:22, [e-mail] (Richard Bos) wrote:

have them, but I would not be surprised at all to learn of embedded ones
that have files, but no directories, and therefore no path names,
absolute or relative.

The Oberon system had no paths.

There was only a large BTree and file names looked like
"myapp.mydocs.letter-written-on-11-may.txt" and there was an API to
retrieve all file names at and after a given prefix. So it worked very
much like a hierachical system.

[Mark McIntyre]

On Fri, 11 May 2007 09:06:52 +0100, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:

>jacob navia wrote:

>Richard Bos a écrit :

>>ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:

>>All operating systems _where this is possible in the first place_. It is
not always possible; for example, under very early versions of MS-DOS,
there was no such thing as a directory. All common modern desktop OSes
have them, but I would not be surprised at all to learn of embedded ones
that have files, but no directories, and therefore no path names,
absolute or relative.

Richard

Nobody cares about those systems.

I bet that's not true.

Safe bet: how many mobile phone systems programmers exist? Not to
mention vehicle management systems, EPOS and a zillion other
environments.

>Living in the past is a favorite passtime of people in this group
apparently.

Speak for yourself - I have a funny feeling that embedded systems make
up a significant part of the future.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Kenneth Brody]

kv******@hotmail.com wrote:
[...]

Is there some way in C to retrieve the absolute path name of the
current directory,

[...]

In straight C, no. (C doesn't even know about "directories".)
However, if you want to expand from straight C into the POSIX
world (which is OT here) you can use getcwd(). If you need
more help, you'll need to ask somewhere else where POSIX is
topical. Perhaps comp.unix.programmer?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[jacob navia]

Mark McIntyre wrote:

On Fri, 11 May 2007 09:06:52 +0100, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:

>>jacob navia wrote:

>>>Richard Bos a écrit :

ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:

>>>>All operating systems _where this is possible in the first place_. It is
not always possible; for example, under very early versions of MS-DOS,
there was no such thing as a directory. All common modern desktop OSes
have them, but I would not be surprised at all to learn of embedded ones
that have files, but no directories, and therefore no path names,
absolute or relative.

Richard

Nobody cares about those systems.

I bet that's not true.

Safe bet: how many mobile phone systems programmers exist? Not to
mention vehicle management systems, EPOS and a zillion other
environments.

Postgres data base in mobile phones?
Did you even READ what the original poster said?

His message started with:

"I've written a piece of code that interfaces with Postgres."

In this context it is stupid to assume he wants his code to run
in some embedded system that hasn't even directories!

But we are lectured about this at every question!

>

>>>Living in the past is a favorite passtime of people in this group
apparently.

Speak for yourself - I have a funny feeling that embedded systems make
up a significant part of the future.

Future "embedded systems" will look more and more like
workstations. Linux has been embedded into a simple watch, for instance.

But embedded systems wasn't the question but the famous

getcwd() function

[Dave Vandervies]

In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>But at each question we have to know apparently how we make the
program portable to MSDOS systems without directories, or whatever.

Living in the past is a favorite passtime of people in this group
apparently.

How about a modern OS under active development, then?

PalmOS (for which there are several mutually mostly-compatible
freestanding C implementations, and I believe at least one hosted one)
supports accessing files on an external memory card, but has no concept
of a directory. As far as the OS is concerned, 'card slot 1, file
"/path/to/file"' IS the filename.

How would you find the "current directory" in a PalmOS program?
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

Your dictionary leaves something to be desired... like a new dictionary.
--James Riden in the scary devil monastery

[jacob navia]

Dave Vandervies wrote:

In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>>But at each question we have to know apparently how we make the
program portable to MSDOS systems without directories, or whatever.

Living in the past is a favorite passtime of people in this group
apparently.

How about a modern OS under active development, then?

PalmOS (for which there are several mutually mostly-compatible
freestanding C implementations, and I believe at least one hosted one)
supports accessing files on an external memory card, but has no concept
of a directory. As far as the OS is concerned, 'card slot 1, file
"/path/to/file"' IS the filename.

How would you find the "current directory" in a PalmOS program?
dave

Hi dave

Two points:

FIRST:
-----

http://www.developer.com/ws/palm/article.php/3508341

Starting from Palm OS 4.0, applications can a utilize new set of
additional system extensions that provide a unified interface for
accessing various expansion capabilities.

....

The Virtual File System Manager is a software layer that manages all
installed file system libraries. The file system is implemented as a
shared library of type sysFileTFileSystem.

Common Operations

VFS Manager supports a standard set of common file operations. They are
listed below, grouped by operation:

Err VFSDirCreate(UInt16 volRefNum, const Char *dirNameP);
Err VFSGetDefaultDirectory(UInt16 volRefNum, const Char *fileTypeStr,
Char *pathStr, UInt16 *bufLenP);
Err VFSRegisterDefaultDirectory(const Char *fileTypeStr,
UInt32 mediaType,
const Char *pathStr);
Err VFSUnregisterDefaultDirectory(const Char *fileTypeStr,
UInt32 mediaType);

This is then, how you manage directories under Palm OS.
It is not good to live in the past :-)

SECOND:
------
I would like to add that the original poster spoke about
"Interfacing to Postgres database". This makes it clear that
he is NOT running in Palm OS or in a coffee machine OS.

[Dave Vandervies]

In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>Dave Vandervies wrote:

>In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>>>But at each question we have to know apparently how we make the
program portable to MSDOS systems without directories, or whatever.

Living in the past is a favorite passtime of people in this group
apparently.

How about a modern OS under active development, then?

PalmOS (for which there are several mutually mostly-compatible
freestanding C implementations, and I believe at least one hosted one)
supports accessing files on an external memory card, but has no concept
of a directory. As far as the OS is concerned, 'card slot 1, file
"/path/to/file"' IS the filename.

How would you find the "current directory" in a PalmOS program?
dave

Hi dave

Two points:

FIRST:
-----

http://www.developer.com/ws/palm/article.php/3508341

Starting from Palm OS 4.0, applications can a utilize new set of
additional system extensions that provide a unified interface for
accessing various expansion capabilities.

[...]

>Err VFSDirCreate(UInt16 volRefNum, const Char *dirNameP);
Err VFSGetDefaultDirectory(UInt16 volRefNum, const Char *fileTypeStr,
Char *pathStr, UInt16 *bufLenP);
Err VFSRegisterDefaultDirectory(const Char *fileTypeStr,
UInt32 mediaType,
const Char *pathStr);
Err VFSUnregisterDefaultDirectory(const Char *fileTypeStr,
UInt32 mediaType);

This is then, how you manage directories under Palm OS.
It is not good to live in the past :-)

If you had actually read the documentation and not just looked at the
names, you would have discovered that these don't actually correspond
to the notion of "directory" as a location in a "directory tree" that you
can move around in, in which you can store "files" that you seem to
be committed to; rather, they provide a way to construct filenames to
access a certain type of file without needing to know where on the card
they're stored when the code is written.
As far as the OS is concerned, all these do is access and manipulate
information about what valid and useful filenames look like. They have
nothing to do with how you access the file once you've figured out
the name.

>SECOND:
------
I would like to add that the original poster spoke about
"Interfacing to Postgres database". This makes it clear that
he is NOT running in Palm OS or in a coffee machine OS.

I would be entirely unsurprised to find that somebody has written code
that will run on a Palm and interface with a database. (Note that the
database doesn't have to be running on the Palm for code running on the
Palm to interface with it.)
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Unfortunately requiring an operating system to function properly is
beyond the authority of the C language standard.
--Jack Klein in comp.lang.c

[Mark McIntyre]

On Fri, 11 May 2007 19:16:19 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Mark McIntyre wrote:

>On Fri, 11 May 2007 09:06:52 +0100, in comp.lang.c , Chris Dollin
<ch**********@hp.comwrote:

Postgres data base in mobile phones?
Did you even READ what the original poster said?

Sure, but what does postgres have to do with whether or not anyone
cares about systems that don't support directories?

If you had said "on a system which uses relational databases, its
unlikely there is not support for directories" you would have been
correct, (though someone would probably have pointed out that at least
one RDBMS zaps the partition and reformats with its own filesystem
that has no directories).

>In this context it is stupid to assume he wants his code to run
in some embedded system that hasn't even directories!

Whats stupid is to say
"nobody cares about such systems".
when you mean
"the OP probably doesn't care about such systems".

The trick is to write what you mean, rather than arrogant-sounding
generalities that annoy people.

>But we are lectured about this at every question!

Well, /you/ certainly are.

>Speak for yourself - I have a funny feeling that embedded systems make
up a significant part of the future.

Future "embedded systems" will look more and more like
workstations.

And the future of desktop computing is diskless workstations.
If Larry can get it wrong, explain why I should believe you...

Myself, I think that future embedded systems will look less and less
like computers at all. Why waste memory and flash with an os that
supports directories, when you're programming the central heating
system?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Fri, 11 May 2007 18:45:13 +0000 (UTC), in comp.lang.c ,
dj******@caffeine.csclub.uwaterloo.ca (Dave Vandervies) wrote:

>I would be entirely unsurprised to find that somebody has written code
that will run on a Palm and interface with a database. (Note that the
database doesn't have to be running on the Palm for code running on the
Palm to interface with it.)

For what its worth, programming for Palm 4.x and below is almost
entirely like working inside a database. You write what are
effectively SPs to access and manipulate data stored in table-like
structures. There's a reason they're called PDBs...

Oh, and there's an ODBC driver for PalmOS.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Dave Vandervies]

In article <ot********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>On Fri, 11 May 2007 18:45:13 +0000 (UTC), in comp.lang.c ,
dj******@caffeine.csclub.uwaterloo.ca (Dave Vandervies) wrote:

>>I would be entirely unsurprised to find that somebody has written code
that will run on a Palm and interface with a database. (Note that the
database doesn't have to be running on the Palm for code running on the
Palm to interface with it.)

For what its worth, programming for Palm 4.x and below is almost
entirely like working inside a database. You write what are
effectively SPs to access and manipulate data stored in table-like
structures. There's a reason they're called PDBs...

Yes. (That's still mostly the case for 5.x as well.) The concept of a
"file" doesn't exist in the Palm's internal storage; you only have files
if there's a memory card in an external expansion slot.
This is one of the reasons why freestanding implementations don't need
to have <stdio.h>.

I doubt that accessing a PDB is anything like interfacing with a Postgres
database, though.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Yet there is no error here, no undefined behavior, no contravention
of anything except good sense.
--Eric Sosman in comp.lang.c

[guru.jois]

On May 11, 5:26 am, [e-mail] (Richard Tobin) wrote:

In article <[e-mail]. com>,

<[e-mail]:

I've written a piece of code that interfaces with Postgres. It needs
to write a Postgres table to disk, which it does with the <COPYcom-
mand. That command requires the absolute file name of the file being
written to. Right now I've got it hard coded to the exact location
where I want it, but that's not very portable. Is there some way in C
to retrieve the absolute path name of the current directory, so that I
could use that in my code and therefore have my code function right no
matter where it's executed? Any information on this would be greatly
appreciated.

There's no portable way to do this in standard C: in fact, C itself
doesn't know anything at all about directories. But all operating
systems provide a way to do it. For example, unix systems have
getcwd() ("get current working directory") which is declared in
<unistd.h>.

This require dynamic memory to hold path length, tough to predict. If
less, lost. If more segfault.
Better try
char * get_current_dir_name(void);
which calls malloc by itself...

>
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Bye
Gururaj.

[Joachim Schmitz]

<gu*******@gmail.comschrieb im Newsbeitrag
news:11**********************@k79g2000hse.googlegr oups.com...

On May 11, 5:26 am, [e-mail] (Richard Tobin) wrote:

>In article <[e-mail]. com>,

....

>There's no portable way to do this in standard C: in fact, C itself
doesn't know anything at all about directories. But all operating
systems provide a way to do it. For example, unix systems have
getcwd() ("get current working directory") which is declared in
<unistd.h>.

This require dynamic memory to hold path length, tough to predict. If
less, lost. If more segfault.
Better try
char * get_current_dir_name(void);
which calls malloc by itself...

as per the manual:
char *getcwd(char *buffer, size_t size)
....
if the buffer parameter is a null pointer, getcwd() uses the malloc()
function to allocate a buffer from the heap of the calling process

getcwd() is POSIX, get_current_dir_name() isn't part of any standard, is it?

Bye, Jojo

[Walter Roberson]

In article <11**********************@k79g2000hse.googlegroups .com>,
gu*******@gmail.com <gu*******@gmail.comwrote:

>On May 11, 5:26 am, [e-mail] (Richard Tobin) wrote:

>In article <[e-mail]. com>,

>There's no portable way to do this in standard C: in fact, C itself
doesn't know anything at all about directories. But all operating
systems provide a way to do it. For example, unix systems have
getcwd() ("get current working directory") which is declared in
<unistd.h>.

>Better try
char * get_current_dir_name(void);
which calls malloc by itself...

get_current_dir_name() appears to be defined only on a limited
range of systems, and only when _GNU_SOURCE is defined. As best
I can tell at the moment, it appears to be part of Linux. Linux
is not unix.
--
All is vanity. -- Ecclesiastes

[jacob navia]

Mark McIntyre wrote:

Myself, I think that future embedded systems will look less and less
like computers at all. Why waste memory and flash with an os that
supports directories, when you're programming the central heating
system?

Because the heating system is supposed to keep statistics
about temperature and oil usage and send them through a
wireless internet connection to the workstation of the administrator
of the building each night at 3AM.

Data is stored in files, and files are best handled with an
OS that has a reasonable file system. Besides, standards are
important and an embedded linux system is much easier to maintain
than a cutomized file system without directories.

An OS provides more capabilities to an embedded system that
allows it to be more useful, without having to develop all
things by yourself.

Linux comes with internet/tcpip stack, file system, and many other
goodies you do not have to develop when you put it in your
system.

And I say "linux" as I would say any *OS*. There are others, simpler
than linux, but with advanced file systems.

[Dave Vandervies]

In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>Data is stored in files, and files are best handled with an
OS that has a reasonable file system.

Counterexample: PalmOS.
It understands filesystems, which lets it read and write external memory
cards using the same language that the rest of the world understands,
but it stores data perfectly well in internal storage without a filesystem
in sight.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
If you guys are going to have a fight, don't mind me - I can always make
a buck on the ticket sales. But make it a nice /clean/ fight, okay?
--Richard Heathfield in comp.lang.c

[CBFalconer]

Dave Vandervies wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

>Data is stored in files, and files are best handled with an
OS that has a reasonable file system.

Counterexample: PalmOS.
It understands filesystems, which lets it read and write external
memory cards using the same language that the rest of the world
understands, but it stores data perfectly well in internal storage
without a filesystem in sight.

What counterexample? So does Linux, CP/M, DOS, even Winblows.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Dave Vandervies]

In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>Dave Vandervies wrote:

>jacob navia <ja***@jacob.remcomp.frwrote:

>>Data is stored in files, and files are best handled with an
OS that has a reasonable file system.

Counterexample: PalmOS.
It understands filesystems, which lets it read and write external
memory cards using the same language that the rest of the world
understands, but it stores data perfectly well in internal storage
without a filesystem in sight.

What counterexample? So does Linux, CP/M, DOS, even Winblows.

I would have to do nontrivial work to get a Linux system to manage data
in persistent storage without a filesystem. (It can of course be done,
but I would have to acquire or build the tools to do it.) The natural
way to store data is in files, and the system makes handling files easy.
I don't have enough (deep enough or recent enough) knowledge of CP/M,
DOS, or Windows to be certain that that's the case there, but I would
be quite surprised if it weren't.
PalmOS is quite happy, out of the box, to store my data without a
filesystem, which makes it a counterexample to navia's claim that data
is stored in files.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I bet half of my CDs are from shops that are now no longer in business. It's
a good thing that they don't need to phone home every 90 days to keep
working, really. --Peter Corlett in the scary devil monastery

[Richard Bos]

Mark McIntyre <ma**********@spamcop.netwrote:

On Fri, 11 May 2007 19:16:19 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

Postgres data base in mobile phones?
Did you even READ what the original poster said?

Sure, but what does postgres have to do with whether or not anyone
cares about systems that don't support directories?

If you had said "on a system which uses relational databases, its
unlikely there is not support for directories" you would have been
correct, (though someone would probably have pointed out that at least
one RDBMS zaps the partition and reformats with its own filesystem
that has no directories).

I *hate* that system. It's completely unmaintainable, and it bloody well
leaks memory.

Nevertheless, it does exist, and anyone writing C code had better be
aware that it, and systems vaguely like it, do exist. And may then
choose to ignore them, of course; but _choose_ to, not assume, from lack
of education, that they do not exist.

Richard

[Lew Pitcher]

On May 16, 11:45 am, [e-mail] (Dave
Vandervies) wrote:

In article <[e-mail]>,

CBFalconer <[e-mail]:

Dave Vandervies wrote:

jacob navia <[e-mail]:

>Data is stored in files, and files are best handled with an
OS that has a reasonable file system.

Counterexample: PalmOS.
It understands filesystems, which lets it read and write external
memory cards using the same language that the rest of the world
understands, but it stores data perfectly well in internal storage
without a filesystem in sight.

What counterexample? So does Linux, CP/M, DOS, even Winblows.

I would have to do nontrivial work to get a Linux system to manage data
in persistent storage without a filesystem.

Well, I guess it depends on what you mean by "a filesystem", and how
much work you consider "nontrivial" to be.

Assuming that a raw device qualifies as "persistant storage without a
filesystem", then it is trivially easy to get a Linux system (or any
Posix system, for that matter) to manage data on it. It can even be
done is ISO standard C:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
FILE *storage;
int datum;

if ((storage = fopen("/dev/hdb", "r+b")) != NULL)
{
fprintf(storage,"%s\n","Persistent data");
fseek(storage,0l,SEEK_SET);
for (datum=fgetc(storage);datum != EOF && datum !=
'\n';datum=fgetc(storage))
putchar(datum);
fclose(storage);
return EXIT_SUCCESS;
}
else return EXIT_FAILURE;
}
[snip]