commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Piwowarski <benjamin.piwowar...@lip6.fr>
Subject Re: [vfs] File permissions
Date Wed, 27 Jun 2012 12:41:44 GMT
Hi,

I posted a patch following the "simple solution for VFS2":

https://issues.apache.org/jira/browse/VFS-405

Benjamin


On Jun 26, 2012, at 18:20 , Gary Gregory wrote:

> On Tue, Jun 26, 2012 at 11:46 AM, Benjamin Piwowarski <
> benjamin.piwowarski@lip6.fr> wrote:
> 
>> Hi,
>> 
>> On Jun 26, 2012, at 17:36 , Gary Gregory wrote:
>> 
>>> After a brief glance, my first impression is that we should stick to
>>> something more simple, like we have now on FileObject. We have
>>> isWritable(), so we could add setWritable().
>>> 
>>> Adding a class hierarchy and more fancy permissions feels like it leaks
>>> into Java 7-land.
>>> 
>>> I see two avenues:
>>> - a simple solution for VFS2
>>> - start VFS3 based on Java 7, which will not look anything like the VFS
>> we
>>> know today.
>> 
>> I agree that it looks a bit like Java 7 (I did not know the new metadata
>> classes, i.e.
>> http://docs.oracle.com/javase/tutorial/essential/io/fileAttr.html ) -
>> actually we could mimic some of the classes for the implementation. I don't
>> know the roadmap for VFS2/3 (when is VFS3 planned if at all?), but going in
>> the VFS3 direction already would reduce the number of modification when
>> upgrading from VFS2.
>> 
> 
> I do not think there is a VFS3 direction beyond "we'll provide Java 7
> FileSystem implementations". Whether or not there is an interoperability
> layer for VFS2 I do not know. I'd rather see a clean break.
> 
>> 
>> I can stick to the current interface though, and add some methods for
>> read/write/execution flags.
>> 
> 
> That seems like the simplest approach today.
> 
> Gary
> 
> 
>> 
>> Benjamin
>> 
>>> 
>>> Gary
>>> 
>>> On Tue, Jun 26, 2012 at 10:52 AM, Benjamin Piwowarski <
>> benjamin@bpiwowar.net
>>>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I started to implement a file permission (or more generally a file
>>>> properties) framework for VFS. I attached a patch to VFS-405 issue (
>>>> https://issues.apache.org/jira/browse/VFS-405 ) since it matches the
>> bug
>>>> description.
>>>> 
>>>> The patch 0001 adds basic permission support in the form of a
>>>> FileProperties (more general) object that can be accessed through
>>>> getFileProperties in FileObject. In the patch, there are four types of
>>>> properties:
>>>>      • FileProperties: the abstract base class
>>>>      • AbstractPermission: the abstract base class for permission
>>>> properties
>>>>      • JavaPermissions: java like file permissions
>>>>      • PosixPermissions: POSIX (user/group/others) permissions
>>>> The patch provides initial support for sftp and local filesystem.
>>>> 
>>>> In the longer term, it would make some methods (isHidden, etc.)
>> deprecated
>>>> since the functionality would be duplicated.
>>>> 
>>>> Please comment on this before I put more efforts in this patch.
>>>> 
>>>> Benjamin
>>>> 
>>>> On Jun 25, 2012, at 20:29 , Gary Gregory wrote:
>>>> 
>>>>> On Mon, Jun 25, 2012 at 1:03 PM, Benjamin Piwowarski
>>>>> <benjamin@bpiwowar.net>wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I was wondering if there were any plans for the "Get/set the file
>>>>>> permissions" item in the TODO list. I would like to contribute on
that
>>>> (at
>>>>>> least for sftp and local), but I would like to know the planned
>>>>>> architecture for such a feature (if any).
>>>>>> 
>>>>> 
>>>>> Not from me ATM. Feel free to give it a go.
>>>>> 
>>>>> Can anyone see reason why we should not have setters like we have
>> getters
>>>>> for:
>>>>> 
>>>>> - org.apache.commons.vfs2.FileObject.isHidden()
>>>>> - org.apache.commons.vfs2.FileObject.isReadable()
>>>>> - org.apache.commons.vfs2.FileObject.isWriteable()
>>>>> 
>>>>> Should there also be other checks? isExecutable()?
>>>>> 
>>>>> Gary
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Thanks
>>>>>> Benjamin Piwowarski
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>>>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>> 
>>>> --
>>>> Benjamin Piwowarski
>>>> LIP6/CNRS, University Pierre et Marie Curie (UPMC)
>>>> case 169 – 4, Place de Jussieu – 75252 Paris cedex 05 – France
>>>> benjamin@bpiwowar.net
>>>> http://www.bpiwowar.net/
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

--
Benjamin Piwowarski
LIP6/CNRS, University Pierre et Marie Curie (UPMC)
case 169 – 4, Place de Jussieu – 75252 Paris cedex 05 – France
benjamin@bpiwowar.net
http://www.bpiwowar.net/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message