Re: [boost] [Boost-users] User/Owner Information And in Boost File System

Subject: Re: [boost] [Boost-users] User/Owner Information And in Boost File System
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-02-12 05:04:32

On Feb 12, 2014, at 12:03 AM, MANTOSH KUMAR <mantosh4u_at_[hidden]> wrote:

> Point::1
> ======
> boost::filesystem library is great. However I found that boost::filesystem has no interface to fetch about the owner(userid/groupid) of a particular file.
> 
> "stat()" system call has been provided by POSIX compliance system to fetch this information. I am pretty sure that this must have been thought by boost community while designing boost::filesystem library and there would be valid reason not to provide such interface. However I just wanted to
> know the thought of boost community.

I don't know whether this was discussed on the list (you can search the archives), and Beman surely knows the answer, but I can imagine the reason is due to portability concerns. That is, the same information is not available from all filesystems.

> Point::2
> ======

These are quite distinct questions and would have been better asked in separate messages.

> The following is the code snippet:
> 
> std::vector<boost::filesystem::path>  vec;
> boost::filesystem::recursive_directory_iterator rbgnitr(p);
> boost::filesystem::recursive_directory_iterator renditr;
> for(boost::filesystem::recursive_directory_iterator  itr = rbgnitr; itr !=
> renditr; ++itr) {
>      v.push_back(*itr);
>  }
> 
> In the above "rbgnitr" does represent the starting node in a directory.
> However It looked bit strange while "renditr" for end node(one beyond end).
> The end node renditr" is basically empty instance of class
> "recursive_directory_iterator".

The default constructor creates an instance with state that is equal to a non-default instance once the end of the iteration has been reached. How could iteration be implemented otherwise? The last file/directory in the sequence isn't known a priori.

The only change one could make is to construct the end iterator with the same path as the begin iterator (plus a flag to mark it as an end iterator), so the path could be part of the comparison operation. That would require saving the starting path in all instances and what would it solve?

___
Rob

(Sent from my portable computation engine)