You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2003/05/24 14:46:51 UTC

Re: cvs commit: apr CHANGES

I don't remember discussion of this on dev@apr?  Work/life/family
have been insane, so I could have missed it.

One of the 'good things' (tm) of APR is that we should be providing
identical behavior across platforms, without the programmer having
to go through platform choices.  Now, some platforms provide that
any arbitrary file can be hidden, and I suppose it's goodness to be
able to create such files hidden, read only (advisory), etc.

But wouldn't it be more effective if we found a way to abstract the
'dot file' concept from unix, such that those files would be automatically
hidden files on Win32/OS2/Netware?  E.g. a file such as '.myfile', starting
with a period, would be tagged as hidden on those platforms that don't
provide the dot construct? 

I understand that SVN and some other apps want some granular
control.  But your patch doesn't offer any APR_HAVE_HIDDEN_FILE
flags.  Taking my theme above, we also might want to have
APR_HAVE_DOT_FILE_HIDDEN or something like that.

Thoughts?

Bill

>brane       2003/05/24 03:30:40
>
>  Modified:    include  apr_file_io.h
>               file_io/win32 filestat.c
>               file_io/unix filestat.c
>               file_io/os2 filestat.c
>               file_io/netware filestat.c
>               .        CHANGES
>  Log:
>  Added flag APR_FILE_ATTR_HIDDEN for manipulating the "hidden" file
>  attribute on Windows and OS/2. Also changed the apr_file_attrs_set
>  implementations to not make any syscalls if the requested attributes
>  are not supported on the platform.
>  
>  --- apr_file_io.h     1 May 2003 03:16:30 -0000       1.139
>  +++ apr_file_io.h     24 May 2003 10:30:39 -0000      1.140
>  @@ -129,6 +129,7 @@
>   /* flags for apr_file_attrs_set */
>   #define APR_FILE_ATTR_READONLY   0x01          /**< File is read-only */
>   #define APR_FILE_ATTR_EXECUTABLE 0x02          /**< File is executable */
>  +#define APR_FILE_ATTR_HIDDEN     0x04          /**< File is hidden */
>   /** @} */
>   
>   /** File attributes */



Re: cvs commit: apr CHANGES

Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:

>I don't remember discussion of this on dev@apr?  Work/life/family
>have been insane, so I could have missed it.
>
There wasn't one, at least not recently. I simply followed the design
that was there, adding another flag.

>One of the 'good things' (tm) of APR is that we should be providing
>identical behavior across platforms, without the programmer having
>to go through platform choices.  Now, some platforms provide that
>any arbitrary file can be hidden, and I suppose it's goodness to be
>able to create such files hidden, read only (advisory), etc.
>
>But wouldn't it be more effective if we found a way to abstract the
>'dot file' concept from unix, such that those files would be automatically
>hidden files on Win32/OS2/Netware?  E.g. a file such as '.myfile', starting
>with a period, would be tagged as hidden on those platforms that don't
>provide the dot construct? 
>
I wondered about that myself. But there are lots of semantic differences
between .foo on *nix and a hidden foo on DOS derivatives.

>I understand that SVN and some other apps want some granular
>control.  But your patch doesn't offer any APR_HAVE_HIDDEN_FILE
>flags.  Taking my theme above, we also might want to have
>APR_HAVE_DOT_FILE_HIDDEN or something like that.
>
>Thoughts?
>
That's not such a bad idea, really. We'd have to add similar flags for
executable (which doesn't exist at all on Windows or OS/2), and perhaps
whether read-only is a flag or a permission state, etc.

I know the apr_file_attrs_set interface was put together in a bit of a
rush. I'm happy with it the way it is now, but it might not be the best
way to do things. So, if we decide to add all sorts of flags, we might
thing about the function itself, and whether it needs changes.


-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/