filesystem hard link question
I am using the following common idiom: link (name, name.old) rename (name.new, name) To update a file atomically I'm interested in using boost::filesystem instead of libc, but I didn't find any equivalent of link in filesystem. Did I miss it? Should it be added?
At 08:45 AM 3/11/2004, Neal D. Becker wrote:
I am using the following common idiom:
link (name, name.old) rename (name.new, name)
To update a file atomically
I'm interested in using boost::filesystem instead of libc, but I didn't find any equivalent of link in filesystem. Did I miss it?
No, it isn't provided.
Should it be added?
It is messy for directories on Windows. That's been the holdup. There are also some other Boost.Filesystem enhancements which have higher priority. So unless someone else wants to work up a proposed Windows implementation, it won't happen anytime soon. Sorry, --Beman
Beman Dawes wrote:
At 08:45 AM 3/11/2004, Neal D. Becker wrote:
I am using the following common idiom:
link (name, name.old) rename (name.new, name)
To update a file atomically
I'm interested in using boost::filesystem instead of libc, but I didn't find any equivalent of link in filesystem. Did I miss it?
No, it isn't provided.
Should it be added?
It is messy for directories on Windows. That's been the holdup. There are also some other Boost.Filesystem enhancements which have higher priority. So unless someone else wants to work up a proposed Windows implementation, it won't happen anytime soon.
You mean no functions can be added to Boost::Filesystem unless they are supported on all systems? I'm surprised (and disappointed).
It is messy for directories on Windows. That's been the holdup. There are also some other Boost.Filesystem enhancements which have higher
At 02:17 PM 3/11/2004, Neal D. Becker wrote: priority.
So unless someone else wants to work up a proposed Windows implementation, it won't happen anytime soon.
You mean no functions can be added to Boost::Filesystem unless they are supported on all systems? I'm surprised (and disappointed).
Portable behavior has always been major aim for the library. The criteria has been that it should be possible to provide POSIX (including the MAC) and Windows implementations which deliver the same behavior for practical purposes. That isn't hard to do with functionality like hard links which are present in most modern operating systems, at least for regular files. But it takes time to reconcile sometimes differing terminology, figure out exactly what can be promised (and what can't be promised), specify the interface, and write test cases and documentation. The actual implementation is often trivial. Then watch the regression tests as they roll out on different systems. --Beman
Beman Dawes <bdawes@acm.org> wrote:
At 08:45 AM 3/11/2004, Neal D. Becker wrote:
Should it be added?
It is messy for directories on Windows. That's been the holdup. There are also some other Boost.Filesystem enhancements which have higher priority. So unless someone else wants to work up a proposed Windows implementation, it won't happen anytime soon.
How about an implementation that just throws when used on Windows? I've got that already written. Regards, Walter Landry wlandry@ucsd.edu
Walter Landry wrote:
Beman Dawes <bdawes@acm.org> wrote:
At 08:45 AM 3/11/2004, Neal D. Becker wrote:
Should it be added?
It is messy for directories on Windows. That's been the holdup. There are also some other Boost.Filesystem enhancements which have higher priority. So unless someone else wants to work up a proposed Windows implementation, it won't happen anytime soon.
How about an implementation that just throws when used on Windows? I've got that already written.
IIRC, cygwin does have some support for hard links? If so, when you say "windows" I guess you mean native windows as opposed to cygwin?
"Neal D. Becker" <ndbecker2@verizon.net> wrote:
Walter Landry wrote:
Beman Dawes <bdawes@acm.org> wrote:
At 08:45 AM 3/11/2004, Neal D. Becker wrote:
Should it be added?
It is messy for directories on Windows. That's been the holdup. There are also some other Boost.Filesystem enhancements which have higher priority. So unless someone else wants to work up a proposed Windows implementation, it won't happen anytime soon.
How about an implementation that just throws when used on Windows? I've got that already written.
IIRC, cygwin does have some support for hard links? If so, when you say "windows" I guess you mean native windows as opposed to cygwin?
It throws whenever BOOST_POSIX is not defined. It is just this (works with 1.30.0, don't know about 1.31.0): void link( const path & from_file_ph, const path & to_file_ph ) { # ifdef BOOST_POSIX if(::link(from_file_ph.native_file_string().c_str(), to_file_ph.native_file_string().c_str()) != 0) # endif boost::throw_exception( filesystem_error( "boost::filesystem::symlink", from_file_ph, to_file_ph, fs::detail::system_error_code() ) ); } Regards, Walter Landry wlandry@ucsd.edu
Walter Landry <wlandry@ucsd.edu> writes:
It throws whenever BOOST_POSIX is not defined. It is just this (works with 1.30.0, don't know about 1.31.0):
void link( const path & from_file_ph, const path & to_file_ph ) { # ifdef BOOST_POSIX if(::link(from_file_ph.native_file_string().c_str(), to_file_ph.native_file_string().c_str()) != 0) # endif boost::throw_exception( filesystem_error( "boost::filesystem::symlink", from_file_ph, to_file_ph, fs::detail::system_error_code() ) ); }
Why is a runtime error better than a compile-time error in this case? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
Walter Landry <wlandry@ucsd.edu> writes:
It throws whenever BOOST_POSIX is not defined. It is just this (works with 1.30.0, don't know about 1.31.0):
void link( const path & from_file_ph, const path & to_file_ph ) { # ifdef BOOST_POSIX if(::link(from_file_ph.native_file_string().c_str(), to_file_ph.native_file_string().c_str()) != 0) # endif boost::throw_exception( filesystem_error( "boost::filesystem::symlink", from_file_ph, to_file_ph, fs::detail::system_error_code() ) ); }
Why is a runtime error better than a compile-time error in this case?
I implemented it this way because it was the easiest thing to do. I'm happy to make it a compile-time error. Regards, Walter Landry wlandry@ucsd.edu
Walter Landry <wlandry@ucsd.edu> writes:
Why is a runtime error better than a compile-time error in this case?
I implemented it this way because it was the easiest thing to do. I'm happy to make it a compile-time error.
I'm asking you/us to figure out what the right response is. I think it's the latter, but someone else should give it some thought. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
Walter Landry <wlandry@ucsd.edu> writes:
Why is a runtime error better than a compile-time error in this case?
I implemented it this way because it was the easiest thing to do. I'm happy to make it a compile-time error.
I'm asking you/us to figure out what the right response is. I think it's the latter, but someone else should give it some thought.
Well, you could argue that making it a run-time error will result in simpler user code. Since everyone should be checking exceptions anyway, user code can decide whether failing to link is fatal. It could, for example, do a copy instead. On the other hand, you won't know until you're running the code whether hard linking will work. That could result in a lot of wasted time. But then if hard linking is not important, the client has to put in #ifdef BOOST_POSIX into their code. That seems icky, but maybe it's just me. In general, I prefer compile-time to run-time errors. Regards, Walter Landry wlandry@ucsd.edu
Beman Dawes <bdawes@acm.org> wrote:
At 08:45 AM 3/11/2004, Neal D. Becker wrote:
Should it be added?
It is messy for directories on Windows. That's been the holdup. There are
also some other Boost.Filesystem enhancements which have higher
At 03:15 PM 3/11/2004, Walter Landry wrote: priority.
So unless someone else wants to work up a proposed Windows
implementation,
it won't happen anytime soon.
How about an implementation that just throws when used on Windows? I've got that already written.
AFAICS there is no reason not to provide the functionality on Windows too, at least for files. It works pretty much the same way as for POSIX, with the caveat that I haven't yet tried to verify that the entire set of behavior for hard links is the same on both OS's. --Beman
"Beman" == Beman Dawes <bdawes@acm.org> writes:
Beman> At 08:45 AM 3/11/2004, Neal D. Becker wrote: >> I'm interested in using boost::filesystem instead of libc, but I didn't >> find any equivalent of link in filesystem. Did I miss it? Beman> No, it isn't provided. >> Should it be added? Beman> It is messy for directories on Windows. That's been the holdup. Directory hardlinks are not provided in any modern system, POSIX has them optional and where present they usually require root privileges. I seriously doubt someone would miss them. ~velco
At 03:45 PM 3/11/2004, Momchil Velikov wrote:
Directory hardlinks are not provided in any modern system, POSIX has them optional and where present they usually require root privileges. I seriously doubt someone would miss them.
I'm not so sure about that, but regardless, an initial version which only supported hard links to files would make a lot of sense. --Beman
I don't believe Windows supports directory hard links. I assume though that you were referring to ``junctions.'' AFAIK, ``junctions'' do not keep the directory `alive', in that I don't believe there is any reference counting, nor do they appear as ordinary directories. Thus, they are more like absolute-path symbolic links than hard links, and I would say therefore it makes more sense to have them be supported by a symbolic link facility rather than by the hard link facility. -- Jeremy Maitin-Shepard
At 08:08 PM 3/11/2004, Jeremy Maitin-Shepard wrote:
I don't believe Windows supports directory hard links. I assume though that you were referring to ``junctions.'' AFAIK, ``junctions'' do not keep the directory `alive', in that I don't believe there is any reference counting, nor do they appear as ordinary directories. Thus, they are more like absolute-path symbolic links than hard links, and I would say therefore it makes more sense to have them be supported by a symbolic link facility rather than by the hard link facility.
Here is what the discussion in the Windows Platform SDK docs says:
A junction (also called a soft link) differs from a hard link in that the
storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer.
Otherwise, junctions operate identically to hard links.
But I take "Otherwise, junctions operate identically to hard links" with a grain of salt, and would want to confirm such an assertion by testing. --Beman
participants (6)
-
Beman Dawes -
David Abrahams -
Jeremy Maitin-Shepard -
Momchil Velikov -
Neal D. Becker -
Walter Landry