Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #6320 > unrolled thread

C++ File Lokcing

Back to article view | Back to comp.lang.c++

Contents

  C++ File Lokcing ruben safir <ruben@mrbrklyn.com> - 2011-06-06 22:41 +0000
    Re: C++ File Lokcing "osmium" <r124c4u102@comcast.net> - 2011-06-06 19:25 -0500
      Re: C++ File Lokcing Juha Nieminen <nospam@thanks.invalid> - 2011-06-07 06:25 +0000
      Re: C++ File Lokcing Öö Tiib <ootiib@hot.ee> - 2011-06-07 00:32 -0700
      Re: C++ File Lokcing ruben safir <ruben@mrbrklyn.com> - 2011-06-07 11:54 -0400
        Re: C++ File Lokcing Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-07 11:55 -0400
          Re: C++ File Lokcing Ruben Safir <ruben@mrbrklyn.com> - 2011-06-07 18:17 +0000
            Re: C++ File Lokcing Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-07 14:23 -0400
              Re: C++ File Lokcing Ruben Safir <ruben@mrbrklyn.com> - 2011-06-07 18:50 +0000
                Re: C++ File Lokcing Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-07 15:16 -0400
                Re: C++ File Lokcing Jeff Flinn <TriumphSprint2000@hotmail.com> - 2011-06-07 15:47 -0400
                Re: C++ File Lokcing Paavo Helde <myfirstname@osa.pri.ee> - 2011-06-07 15:04 -0500
                  Re: C++ File Lokcing Ruben Safir <ruben@mrbrklyn.com> - 2011-06-07 22:46 +0000
                    Re: C++ File Lokcing Nobody <nobody@nowhere.com> - 2011-06-08 07:50 +0100
                      Re: C++ File Lokcing Sherm Pendley <sherm.pendley@gmail.com> - 2011-06-08 20:55 -0400
                        Re: C++ File Lokcing Öö Tiib <ootiib@hot.ee> - 2011-06-08 18:33 -0700
                Re: C++ File Lokcing Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-08 07:43 +0000
              Re: C++ File Lokcing Nobody <nobody@nowhere.com> - 2011-06-07 21:21 +0100
            Re: C++ File Lokcing Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-08 07:21 +0000
            Re: C++ File Lokcing Paavo Helde <myfirstname@osa.pri.ee> - 2011-06-08 16:14 -0500
              Re: C++ File Lokcing drew@furrfu.invalid (Drew Lawson) - 2011-06-08 22:19 +0000
              Re: C++ File Lokcing Nobody <nobody@nowhere.com> - 2011-06-09 02:54 +0100

Page 1 of 2  [1] 2  Next page →

#6320 — C++ File Lokcing

Is there a C++ specific means of file locking?

Ruben

[toc] | [next] | [standalone]

#6322

"ruben safir" wrote:

> Is there a C++ specific means of file locking?

No.  File locking is provided by the operating system, not an ordinary user 
program, which is what a C++ compiler produces. 

[toc] | [prev] | [next] | [standalone]

#6328

osmium <r124c4u102@comcast.net> wrote:
> "ruben safir" wrote:
> 
>> Is there a C++ specific means of file locking?
> 
> No.  File locking is provided by the operating system, not an ordinary user 
> program, which is what a C++ compiler produces. 

  That answer makes no sense. There are tons of things that are provided 
by the OS which a normal program can use, such as reading and writing 
files, allocating memory, printing to stdout, etc.

  The correct answer is: No, the C++ standard does not provide any 
standard mechanism for file locking. For that you'll have to resort to 
some external system-specific functions such as the ones provided by the 
POSIX standard or your OS API.

[toc] | [prev] | [next] | [standalone]

#6335

On Jun 7, 9:33 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> "osmium" <r124c4u...@comcast.net> writes:
> >"ruben safir" wrote:
> >>Is there a C++ specific means of file locking?
> >No.  File locking is provided by the operating system, not an ordinary user
> >program, which is what a C++ compiler produces.
>
>   This must be the correct answer, because Linus Torvalds also
>   says that a C++ compiler cannot produce an operating system!
>
>   (The real reason is - of coures - just that the C++ standard
>   library does not provide this feature, but this might change
>   in the future.)

Actually it is feature of file system. If it is some network file
system then the code that your compiler produces are not implementing
it but the server is. So implementation can do nothing there in order
to achieve that the locks work or not.

[toc] | [prev] | [next] | [standalone]

#6359

On 06/07/2011 02:33 AM, Stefan Ram wrote:
> "osmium"<r124c4u102@comcast.net>  writes:
>> "ruben safir" wrote:
>>> Is there a C++ specific means of file locking?
>> No.  File locking is provided by the operating system, not an ordinary user
>> program, which is what a C++ compiler produces.
>
>    This must be the correct answer, because Linus Torvalds also
>    says that a C++ compiler cannot produce an operating system!
>
>    (The real reason is - of coures - just that the C++ standard
>    library does not provide this feature, but this might change
>    in the future.)
>


I have to do file locking on Linux.  Do you have a recommendation?

Ruben

[toc] | [prev] | [next] | [standalone]

#6360

On 6/7/2011 11:54 AM, ruben safir wrote:
> On 06/07/2011 02:33 AM, Stefan Ram wrote:
>> "osmium"<r124c4u102@comcast.net> writes:
>>> "ruben safir" wrote:
>>>> Is there a C++ specific means of file locking?
>>> No. File locking is provided by the operating system, not an ordinary
>>> user
>>> program, which is what a C++ compiler produces.
>>
>> This must be the correct answer, because Linus Torvalds also
>> says that a C++ compiler cannot produce an operating system!
>>
>> (The real reason is - of coures - just that the C++ standard
>> library does not provide this feature, but this might change
>> in the future.)
>>
>
>
> I have to do file locking on Linux. Do you have a recommendation?

How about news:comp.os.linux.development.apps ?

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#6368

On Tue, 07 Jun 2011 11:55:36 -0400, Victor Bazarov wrote:

> On 6/7/2011 11:54 AM, ruben safir wrote:
>> On 06/07/2011 02:33 AM, Stefan Ram wrote:
>>> "osmium"<r124c4u102@comcast.net> writes:
>>>> "ruben safir" wrote:
>>>>> Is there a C++ specific means of file locking?
>>>> No. File locking is provided by the operating system, not an ordinary
>>>> user
>>>> program, which is what a C++ compiler produces.
>>>
>>> This must be the correct answer, because Linus Torvalds also says that
>>> a C++ compiler cannot produce an operating system!
>>>
>>> (The real reason is - of coures - just that the C++ standard library
>>> does not provide this feature, but this might change in the future.)
>>>
>>>
>>
>> I have to do file locking on Linux. Do you have a recommendation?
> 
> How about news:comp.os.linux.development.apps ?
> 
> V

But Victor, if you can't file lock with posix file locking, then there is 
almost no use of ios_base for file systems.  You have to lock files on a 
multiuser OS before you write to them.  Can you get the file descriptor 
from ofsream or can you feed flock()?

Ruben

[toc] | [prev] | [next] | [standalone]

#6370

On 6/7/2011 2:17 PM, Ruben Safir wrote:
> On Tue, 07 Jun 2011 11:55:36 -0400, Victor Bazarov wrote:
>
>> On 6/7/2011 11:54 AM, ruben safir wrote:
>>> On 06/07/2011 02:33 AM, Stefan Ram wrote:
>>>> "osmium"<r124c4u102@comcast.net>  writes:
>>>>> "ruben safir" wrote:
>>>>>> Is there a C++ specific means of file locking?
>>>>> No. File locking is provided by the operating system, not an ordinary
>>>>> user
>>>>> program, which is what a C++ compiler produces.
>>>>
>>>> This must be the correct answer, because Linus Torvalds also says that
>>>> a C++ compiler cannot produce an operating system!
>>>>
>>>> (The real reason is - of coures - just that the C++ standard library
>>>> does not provide this feature, but this might change in the future.)
>>>>
>>>>
>>>
>>> I have to do file locking on Linux. Do you have a recommendation?
>>
>> How about news:comp.os.linux.development.apps ?
>>
>> V
>
> But Victor, if you can't file lock with posix file locking, then there is
> almost no use of ios_base for file systems.  You have to lock files on a
> multiuser OS before you write to them.  Can you get the file descriptor
> from ofsream or can you feed flock()?

But Ruben, there is no such thing in C++ as "file descriptor".  POSIX 
and C++ are orthogonal, not part of each other.  On some systems there 
*may* be a way to get something from 'std::ios_base' other than what the 
Standard specifies, but it's *not* specified by the Standard, and that's 
why you need to *ask elsewhere*.  Can you not see that?

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#6371

> But Ruben, there is no such thing in C++ as "file descriptor".  POSIX
> and C++ are orthogonal, not part of each other.  On some systems there
> *may* be a way to get something from 'std::ios_base' other than what the
> Standard specifies, but it's *not* specified by the Standard, and that's
> why you need to *ask elsewhere*.  Can you not see that?
> 
> V

Reading that other newsgroup for over a decade, I can tell you that 
nobody there has the expertise in C++ to event shine your toe nail.

Talking to friends at Google, evidently they don't use ios base for file 
access.  They use unistd.h, fcntl.h, sys/file.h, 

something is wrong,  I'm not trolling, but it is fustrating me and 
puzzles me too spend a month learning the details of a rather exotic 
iostream class in C++ and then to find that it is all but useless because 
you can't lock the files,

Ruben

[toc] | [prev] | [next] | [standalone]

#6372

On 6/7/2011 2:50 PM, Ruben Safir wrote:
>
>> But Ruben, there is no such thing in C++ as "file descriptor".  POSIX
>> and C++ are orthogonal, not part of each other.  On some systems there
>> *may* be a way to get something from 'std::ios_base' other than what the
>> Standard specifies, but it's *not* specified by the Standard, and that's
>> why you need to *ask elsewhere*.  Can you not see that?
>>
>> V
>
> Reading that other newsgroup for over a decade, I can tell you that
> nobody there has the expertise in C++ to event shine your toe nail.
>
> Talking to friends at Google, evidently they don't use ios base for file
> access.  They use unistd.h, fcntl.h, sys/file.h,
>
> something is wrong,  I'm not trolling, but it is fustrating me and
> puzzles me too spend a month learning the details of a rather exotic
> iostream class in C++ and then to find that it is all but useless because
> you can't lock the files,

You *have* to use the means offered by the OS for file locking, there is 
no choice in that.  The Standard C++ Library simply *has no such means*.

There are some choices available, as I see it.  *If* there is a way to 
lock the file at the OS level by the file *name*, you can open it using 
C++ mechanism *after* it's been locked.  The other way is to use *the OS 
means* to do all file-related manipulations, including I/O (reading and 
writing), *if* locking is only possible during/after opening.  The 
former way would allow easy use of 'ofstream' (if you so desire).  The 
latter way would force you to use reading/writing using POSIX (not that 
bad), but you *could* lose the desired functionality of 'ostream'.

Since there is no file locking in C++ (as it's defined in its Standard), 
you sill need to ask elsewhere (regardless of their C++ abilities). 
Having learned how to lock files in your OS, try writing your program in 
C++ and if you experience problems (C++ problems, not OS problems), come 
back and ask about them.

There are other places where you should consider asking.  There is the 
compiler newsgroup, gnu.g++.help (if you're using G++), for instance.

Programming a specific OS will need to be learned, and you're capable of 
learning it, I am sure.  Unfortunately, *this newsgroup* is *not* the 
place to do that.

Good luck!

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#6373

Ruben Safir wrote:
>> But Ruben, there is no such thing in C++ as "file descriptor".  POSIX
>> and C++ are orthogonal, not part of each other.  On some systems there
>> *may* be a way to get something from 'std::ios_base' other than what the
>> Standard specifies, but it's *not* specified by the Standard, and that's
>> why you need to *ask elsewhere*.  Can you not see that?
>>
>> V
> 
> Reading that other newsgroup for over a decade, I can tell you that 
> nobody there has the expertise in C++ to event shine your toe nail.
> 
> Talking to friends at Google, evidently they don't use ios base for file 
> access.  They use unistd.h, fcntl.h, sys/file.h, 
> 
> something is wrong,  I'm not trolling, but it is fustrating me and 
> puzzles me too spend a month learning the details of a rather exotic 
> iostream class in C++ and then to find that it is all but useless because 
> you can't lock the files,

The boost.iostreams library provides streams interface with file 
descriptor and it's flags. See:

http://www.boost.org/doc/libs/1_46_1/libs/iostreams/doc/classes/file_descriptor.html#file_descriptor_constructor

Jeff

[toc] | [prev] | [next] | [standalone]

#6374

Ruben Safir <ruben@mrbrklyn.com> wrote in
news:islrua$rhi$4@reader1.panix.com: 

> 
> something is wrong,  I'm not trolling, but it is fustrating me and 
> puzzles me too spend a month learning the details of a rather exotic 
> iostream class in C++ and then to find that it is all but useless
> because you can't lock the files,

Yes, the C++ standard attempts to factor out some common functionality 
which could be provided on every platform. Unfortunately some 
functionality got thrown out with the water this way. 

If you are fine with POSIX flock() then there is nothing wrong with using 
it. The C++ stream interface is most concerned with formatting the data 
in some kind of textual representation, I have never had much need for 
that, except for some kind of in-memory conversions which are mostly 
covered by boost::lexical_cast() anyway. When one writes an actual disk 
file, it will be most often in some special binary format anyway so there 
is no use for the c++ streams facility. 

hth
Paavo

[toc] | [prev] | [next] | [standalone]

#6384

On Tue, 07 Jun 2011 20:50:16 +0000, Stefan Ram wrote:

> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>Yes, the C++ standard attempts to factor out some common functionality
>>which could be provided on every platform.
> 
>       »Library extensions will be considered even if they cannot be
>       implemented on every platform«
> 
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1314.htm
> 
>   (That quotation, which just had become 10 years old, was found on
> 
> http://www.purl.org/stefan_ram/pub/c++_standard_extensions_en
> 
>   .)


I know I'm ignorant, but I would think that file locking is a universal 
need all all OS's.  As for the low level implementation, leave it to the 
compiler.

As sure as reading and writing to the fs is universal, show should locking
for multiple users and programs.

Ruben

[toc] | [prev] | [next] | [standalone]

#6394

On Tue, 07 Jun 2011 22:46:57 +0000, Ruben Safir wrote:

> I know I'm ignorant, but I would think that file locking is a universal 
> need all all OS's.  As for the low level implementation, leave it to the 
> compiler.

Some form of locking may exist on most multi-user and/or multi-tasking
OSes, but the nature of such locking may vary wildly.

Can you lock byte ranges or just the whole file? Can you lock to the end
of the file such that the range will be extended to cover appended data?
Are locks advisory (a lock only prevents further locks) or mandatory (a
lock directly prevents reading or writing)? And so on.

Some of these aspects aren't even standardised across Unix systems, let
alone other platforms.

[toc] | [prev] | [next] | [standalone]

#6461

Nobody <nobody@nowhere.com> writes:

> On Tue, 07 Jun 2011 22:46:57 +0000, Ruben Safir wrote:
>
>> I know I'm ignorant, but I would think that file locking is a universal 
>> need all all OS's.  As for the low level implementation, leave it to the 
>> compiler.
>
> Some form of locking may exist on most multi-user and/or multi-tasking
> OSes, but the nature of such locking may vary wildly.
>
> Can you lock byte ranges or just the whole file? Can you lock to the end
> of the file such that the range will be extended to cover appended data?
> Are locks advisory (a lock only prevents further locks) or mandatory (a
> lock directly prevents reading or writing)? And so on.
>
> Some of these aspects aren't even standardised across Unix systems, let
> alone other platforms.

Obviously the implementations vary, but surely there's a minimal set of
functionality that's reasonably common? Why couldn't the interface to
at least that set be standardized, with its implementation defined as
vendor specific?

sherm--

[toc] | [prev] | [next] | [standalone]

#6467

On Jun 9, 3:55 am, Sherm Pendley <sherm.pend...@gmail.com> wrote:
> Nobody <nob...@nowhere.com> writes:
> > On Tue, 07 Jun 2011 22:46:57 +0000, Ruben Safir wrote:
>
> >> I know I'm ignorant, but I would think that file locking is a universal
> >> need all all OS's.  As for the low level implementation, leave it to the
> >> compiler.
>
> > Some form of locking may exist on most multi-user and/or multi-tasking
> > OSes, but the nature of such locking may vary wildly.
>
> > Can you lock byte ranges or just the whole file? Can you lock to the end
> > of the file such that the range will be extended to cover appended data?
> > Are locks advisory (a lock only prevents further locks) or mandatory (a
> > lock directly prevents reading or writing)? And so on.
>
> > Some of these aspects aren't even standardised across Unix systems, let
> > alone other platforms.
>
> Obviously the implementations vary, but surely there's a minimal set of
> functionality that's reasonably common? Why couldn't the interface to
> at least that set be standardized, with its implementation defined as
> vendor specific?

Maybe read wikipedia "file locking". Reasonably common set of
functionality is nothing. Hard to standardize there something
additionally because that nothing is already present in standard
library. ;)

[toc] | [prev] | [next] | [standalone]

#6398

On Tue, 2011-06-07, Ruben Safir wrote:
>
>> But Ruben, there is no such thing in C++ as "file descriptor".  POSIX
>> and C++ are orthogonal, not part of each other.  On some systems there
>> *may* be a way to get something from 'std::ios_base' other than what the
>> Standard specifies, but it's *not* specified by the Standard, and that's
>> why you need to *ask elsewhere*.  Can you not see that?
>> 
>> V
>
> Reading that other newsgroup for over a decade, I can tell you that 
> nobody there has the expertise in C++ to event shine your toe nail.
>
> Talking to friends at Google, evidently they don't use ios base for file 
> access.  They use unistd.h, fcntl.h, sys/file.h, 
>
> something is wrong,  I'm not trolling, but it is fustrating me and 
> puzzles me too spend a month learning the details of a rather exotic 
> iostream class in C++ and then to find that it is all but useless because 
> you can't lock the files,

You are IMHO overestimating the need for file locking, but in general
you have a point. If you target (say) Unix you have a lot of
OS-specific things you want to do (select(2) is high on my list) and
standard iostreams doesn't try to help you.

Don't discard iostreams because of that though.
It *does* provide essential features, such as:
- printing to a std::string
- output of user-defined types
- a simple way reading lines of text without buffer overflow

I sometimes wish the C++ standard library was more like Python.
Python's library happily provides Unix-specific features. You can mix
their high-level constructs with the Unix C APIs you're already
familiar with. (This of course decreases the portability of your code,
but that's usually not a problem.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#6375

On Tue, 07 Jun 2011 14:23:13 -0400, Victor Bazarov wrote:

> But Ruben, there is no such thing in C++ as "file descriptor".  POSIX 
> and C++ are orthogonal, not part of each other.  On some systems there 
> *may* be a way to get something from 'std::ios_base' other than what the 
> Standard specifies,

std::ios_base is for streams in general, not necessarily file streams. I'm
fairly sure there's no way to get a file descriptor for a stringstream on
any platform.

To the extent that there's a "standard" way to do this, filebuf::fd()
seems to be it (even MSVC seems to have it). Alternatively, there may be a
filebuf(int fd) constructor.

[toc] | [prev] | [next] | [standalone]

#6397

On Tue, 2011-06-07, Ruben Safir wrote:
> On Tue, 07 Jun 2011 11:55:36 -0400, Victor Bazarov wrote:
...
>>> I have to do file locking on Linux. Do you have a recommendation?
>> 
>> How about news:comp.os.linux.development.apps ?
>> 
>> V
>
> But Victor, if you can't file lock with posix file locking, then there is 
> almost no use of ios_base for file systems.  You have to lock files on a 
> multiuser OS before you write to them.

No you don't. /Almost/ all of the time it's perfectly acceptable to
leave that up to the user. At least in Unix that works (surprisingly)
well.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#6445

Ruben Safir <ruben@mrbrklyn.com> wrote in
news:islpuv$rhi$1@reader1.panix.com: 

> But Victor, if you can't file lock with posix file locking, then there
> is almost no use of ios_base for file systems.  You have to lock files
> on a multiuser OS before you write to them.  Can you get the file
> descriptor from ofsream or can you feed flock()?

On a multiuser OS one should not have many files writable by multiple 
users. This would compromise security as a malicious user could change the 
data of another user. File locking would not prevent that as the lock is 
only temporary (and in case of flock(), only advisory). So normally the 
files a user can write to are used by himself only and non-writable by 
others, meaning there is no specific problem with a multiuser OS.

For flock(), the lock is only advisory anyway, so all programs accessing 
the file must actively cooperate. These days much of the stuff is also NFS-
mounted and flock() does not work there, so I would say it has only a very 
limited niche applicaton. No need to standardize something like that.

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web