Is it possible to lock a file with Boost.Filesystem to prevent its deletion, writing or reading? Adam Badura
On 04/12/2010 11:20 AM, Adam Badura wrote:
Is it possible to lock a file with Boost.Filesystem to prevent its deletion, writing or reading?
Against whom/what do you want to lock the file? On which platform? You can find file locking mechanism in boost.interprocess. Frank
Is it possible to lock a file with Boost.Filesystem to prevent its deletion, writing or reading?
Against whom/what do you want to lock the file? On which platform?
Against other processes will suffice I guess. On Windows platform, however using Boost.Filesystem I hope for (at least some) platform independence. Adam Badura
As far as I know on Unix there is only cooperative locking, meaning you
can lock a file but other processes have to explicitly check whether that
lock is set and handle that.
Immanuel
On Tue, Apr 13, 2010 at 10:02 AM, Adam Badura
Is it possible to lock a file with Boost.Filesystem to prevent its deletion, writing or reading?
Against whom/what do you want to lock the file? On which platform?
Against other processes will suffice I guess. On Windows platform, however using Boost.Filesystem I hope for (at least some) platform independence.
Adam Badura
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 04/13/2010 10:02 AM, Adam Badura wrote:
Is it possible to lock a file with Boost.Filesystem to prevent its deletion, writing or reading?
Against whom/what do you want to lock the file? On which platform?
Against other processes will suffice I guess. On Windows platform, however using Boost.Filesystem I hope for (at least some) platform independence.
To clarify this. Your application is made up from several processes and you want to implement locking between those or do you want to lock against completely unrelated processes? For the first case you can use boost.interprocess for the second case i don't see a portable solution as for example POSIX systems are implementing advisory locking (as opposed to mandatory locking on Windows). On such system you can only have locking between cooperating processes which are obeying to a locking protocol. Frank
I think with rename/move you can accomplish that in a way, however it has
its limitations.
Rune
On Tue, Apr 13, 2010 at 10:46 AM, Frank Meerkötter
On 04/13/2010 10:02 AM, Adam Badura wrote:
Is it possible to lock a file with Boost.Filesystem to prevent its deletion, writing or reading?
Against whom/what do you want to lock the file? On which platform?
Against other processes will suffice I guess. On Windows platform, however using Boost.Filesystem I hope for (at least some) platform independence.
To clarify this. Your application is made up from several processes and you want to implement locking between those or do you want to lock against completely unrelated processes?
For the first case you can use boost.interprocess for the second case i don't see a portable solution as for example POSIX systems are implementing advisory locking (as opposed to mandatory locking on Windows). On such system you can only have locking between cooperating processes which are obeying to a locking protocol.
Frank _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
To clarify this. Your application is made up from several processes and you want to implement locking between those or do you want to lock against completely unrelated processes?
Unrelated processes. Safety of some recovery operations depends on some specific files to not be modified (or deleted) in the mean time. Thus I wanted to lock them.
For the first case you can use boost.interprocess for the second case i don't see a portable solution as for example POSIX systems are implementing advisory locking (as opposed to mandatory locking on Windows). On such system you can only have locking between cooperating processes which are obeying to a locking protocol.
This answers my question ("immanuel litzroth" answered it as well but more briefly). Thanks. Adam Badura
participants (4)
-
Adam Badura -
Frank Meerkötter -
immanuel litzroth -
Rune Lund Olesen