You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Yannick Menager <ym...@yahoo.co.uk> on 2005/12/09 17:54:34 UTC
[VFS] setting read-only, hidden, etc
I'm making a prototype of File to VFS adaptor
(http://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/util/jio/),
which made me realise that there is no support for setting a bunch of
stuff like read-only, hidden, etc, that a File does...
If there is getters for that information, there should be setters too...
So i'd propose to
1) Add setters for those operations
2) Deprecate or remove the getters, add a new Service/Action/Operation
that allow to get/set that information.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] setting read-only, hidden, etc
Posted by Andy Lewis <aj...@ascii27.net>.
By the way - I haven't said this in a while - VFS absolutely ROCKS!
Congratulations (a bit late though) on getting out of the sandbox and
closing on a final release.
Mario Ivankovits wrote:
> Hi Andy!
>
>> So I guess mapping it would be easy, but I would think in that case
>> we would want to have discoverable capabilities for determining if
>> more than one user, group etc can be added so that programmatically
>> such things are predictable.
>
> Yes, thats fair.
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] setting read-only, hidden, etc
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Andy!
> So I guess mapping it would be easy, but I would think in that case we
> would want to have discoverable capabilities for determining if more
> than one user, group etc can be added so that programmatically such
> things are predictable.
Yes, thats fair.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] setting read-only, hidden, etc
Posted by Andy Lewis <aj...@ascii27.net>.
It could be mapped, but would have a lot of additional constraints. For
example with an ACL, you can generally assign any permission to any user
or group. With Unix-like - you only get one definable group, one fixed
group (other), and one user. So I guess mapping it would be easy, but I
would think in that case we would want to have discoverable capabilities
for determining if more than one user, group etc can be added so that
programmatically such things are predictable.
Mario Ivankovits wrote:
> Hi Andy!
>
>> The reality does remain however that some level of native interface
>> will be required for many of these, but that is an implementation
>> detail that matters for each specific file system and should not
>> prevent adding a support framework to VFS. While I haven't looked at
>> what the underlying library support, it occurs to me that a CIFS
>> system might be the ideal candidate to use for developing the ACL
>> test case as it should be doable with no native code.
>
> Yes, I thought to start with CIFS too.
> But didnt you think it might be possible to map the simple unix like
> permissions into a ACL like structure?
> I think the ACL is the way to go, especially as there already exists
> implementatins for linux too.
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] setting read-only, hidden, etc
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Andy!
> The reality does remain however that some level of native interface
> will be required for many of these, but that is an implementation
> detail that matters for each specific file system and should not
> prevent adding a support framework to VFS. While I haven't looked at
> what the underlying library support, it occurs to me that a CIFS
> system might be the ideal candidate to use for developing the ACL test
> case as it should be doable with no native code.
Yes, I thought to start with CIFS too.
But didnt you think it might be possible to map the simple unix like
permissions into a ACL like structure?
I think the ACL is the way to go, especially as there already exists
implementatins for linux too.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] renaming file with only case differences
Posted by Henri Yandell <fl...@gmail.com>.
On 5/2/06, Filip Defoort <fi...@cirquedigital.com> wrote:
> Hi,
>
> I'm running in the following problem: VFS doesn't seem to be able to
> rename a file to another name when only the case is different. On windows,
> since the file system is case insensitive, File.exists() returns true, which
> causes FileObject.moveTo() to actually delete the source file (since it's
> considered the same file as the target).... that's obviously not
> desirable...
>
> Anybody any ideas on how I can do a proper rename ? Would it be better
> to have a separeate renameTo method (not moveTo) that would not delete
> the target first ?
Would think that VFS could be asking what the canonical name of the
two files are, and if they equal each other then it does a no-op.
Might be of value on OS X too, not sure how its flirtation with case
insensitivity affects the JVM.
Not looked at the source before though, so just a thought.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] accessing FileObjects from different threads
Posted by Filip Defoort <fi...@cirquedigital.com>.
Hi Mario,
Follow-up on today's testing: indeed, no more deadlock problems. Yeah!
I did notice one thing, that is that the behaviour of
FileObject.listChildren() seems
to have changed. It now throw an exception when you do a list children on a
file (as opposed to a folder). I believe it simply returned null or an
empty array
before.
Not sure if this change is intended or if it's a side-effect of some of
the changes...
Thanks!
- Filip
Filip Defoort wrote:
> Hi Mario,
>
> Indeed -- it's been a while again... too little time, too many things
> to do;
> but I keep coming back to VFS :-D. Still would love to find the time
> to improve the normalization...
>
> It's primarily reads of metadata about the FileObjects that I think
> are causing
> the problems (listChildren(), getType(),...) -- I don't touch the
> actual content
> often enough to show any signs there. It showed up after switching
> to RC8-snapshot to work around the cache freshness problem and some
> changes in my code to page in information on demand as the main
> tables scroll independently.
>
> The symptom is either deadlock on FileObject synchronization or NPE,
> depending on the test.
>
> I'll have testing done tomorrow with HEAD and see if it props up with
> the very latest
> VFS (without the SynchronizedFileObject decoration) and will let you
> know... If the problem is still there, I can get you the thread dumps...
>
> Thanks and Cheers!
> - Filip
>
>
>
>
> Mario Ivankovits wrote:
>> Hi Filip, nice to read you again.
>>
>>
>>> Sometimes, the FileObject gets detached while it's still being used by
>>> another
>>> thread causing exceptions and sometimes the FileObject go into a
>>> deadlock.
>>>
>> As you already noticed ( you are bleedingly fast) :-) I committed a try
>> to fix this issue.
>> Maybe if you simply try the svn head version it might behave better
>> already without any additional change. But for sure, if one thread tries
>> to copy the file and another one deletes it at the same time you'll get
>> exceptions again.
>> Could you please provide more informations about the operations you try
>> in parallel on the same fileObject?
>>
>> The next NEW thing you can try is, to decorate the file object so that
>> it will synchronize each call.
>>
>> StandardFileSystemManager manager = new
>> StandardFileSystemManager();
>> manager.setCacheStrategy(CacheStrategy.ON_RESOLVE);
>> manager.setFileObjectDecorator(SynchronizedFileObject.class);
>> manager.init();
>>
>> if you use instanceof with your FileObjects you have to change this to
>> FileObjectUtils.isInstanceOf
>>
>> However, the deadlock problem might be more problematic. We need a "full
>> thread dump" to figure out whats the problem.
>> Also the SynchronizedFileObject might introduce new deadlocks as it
>> synchronize against the fileObject instance, internally the FileObject
>> itself has to synchronize against the fileSystem .... but hey, its a
>> try.
>>
>> Could you please check this out.
>>
>> Thanks!
>> Ciao,
>> Mario
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] accessing FileObjects from different threads
Posted by Filip Defoort <fi...@cirquedigital.com>.
Hi Mario,
Indeed -- it's been a while again... too little time, too many things to do;
but I keep coming back to VFS :-D. Still would love to find the time
to improve the normalization...
It's primarily reads of metadata about the FileObjects that I think are
causing
the problems (listChildren(), getType(),...) -- I don't touch the actual
content
often enough to show any signs there. It showed up after switching
to RC8-snapshot to work around the cache freshness problem and some
changes in my code to page in information on demand as the main
tables scroll independently.
The symptom is either deadlock on FileObject synchronization or NPE,
depending on the test.
I'll have testing done tomorrow with HEAD and see if it props up with
the very latest
VFS (without the SynchronizedFileObject decoration) and will let you
know... If the problem is still there, I can get you the thread dumps...
Thanks and Cheers!
- Filip
Mario Ivankovits wrote:
> Hi Filip, nice to read you again.
>
>
>> Sometimes, the FileObject gets detached while it's still being used by
>> another
>> thread causing exceptions and sometimes the FileObject go into a
>> deadlock.
>>
> As you already noticed ( you are bleedingly fast) :-) I committed a try
> to fix this issue.
> Maybe if you simply try the svn head version it might behave better
> already without any additional change. But for sure, if one thread tries
> to copy the file and another one deletes it at the same time you'll get
> exceptions again.
> Could you please provide more informations about the operations you try
> in parallel on the same fileObject?
>
> The next NEW thing you can try is, to decorate the file object so that
> it will synchronize each call.
>
> StandardFileSystemManager manager = new StandardFileSystemManager();
> manager.setCacheStrategy(CacheStrategy.ON_RESOLVE);
> manager.setFileObjectDecorator(SynchronizedFileObject.class);
> manager.init();
>
> if you use instanceof with your FileObjects you have to change this to
> FileObjectUtils.isInstanceOf
>
> However, the deadlock problem might be more problematic. We need a "full
> thread dump" to figure out whats the problem.
> Also the SynchronizedFileObject might introduce new deadlocks as it
> synchronize against the fileObject instance, internally the FileObject
> itself has to synchronize against the fileSystem .... but hey, its a try.
>
> Could you please check this out.
>
> Thanks!
> Ciao,
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] accessing FileObjects from different threads
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Filip, nice to read you again.
> Sometimes, the FileObject gets detached while it's still being used by
> another
> thread causing exceptions and sometimes the FileObject go into a
> deadlock.
As you already noticed ( you are bleedingly fast) :-) I committed a try
to fix this issue.
Maybe if you simply try the svn head version it might behave better
already without any additional change. But for sure, if one thread tries
to copy the file and another one deletes it at the same time you'll get
exceptions again.
Could you please provide more informations about the operations you try
in parallel on the same fileObject?
The next NEW thing you can try is, to decorate the file object so that
it will synchronize each call.
StandardFileSystemManager manager = new StandardFileSystemManager();
manager.setCacheStrategy(CacheStrategy.ON_RESOLVE);
manager.setFileObjectDecorator(SynchronizedFileObject.class);
manager.init();
if you use instanceof with your FileObjects you have to change this to
FileObjectUtils.isInstanceOf
However, the deadlock problem might be more problematic. We need a "full
thread dump" to figure out whats the problem.
Also the SynchronizedFileObject might introduce new deadlocks as it
synchronize against the fileObject instance, internally the FileObject
itself has to synchronize against the fileSystem .... but hey, its a try.
Could you please check this out.
Thanks!
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] accessing FileObjects from different threads
Posted by Filip Defoort <fi...@cirquedigital.com>.
Saw some fixes in the latest svn trunk -- I believe those address the
problem
I was having....
Keeping fingers crossed...
- Filip
Filip Defoort wrote:
> Hi,
>
> I'm accessing VFS FileObjects from different threads and running into
> some
> synchronization problems (using the ON_RESOLVE cache strategy).
>
> Sometimes, the FileObject gets detached while it's still being used by
> another
> thread causing exceptions and sometimes the FileObject go into a
> deadlock.
>
> What are the rules for accessing FileObjects from different threads ?
>
> Many thanks in advance,
> - Filip
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[VFS] accessing FileObjects from different threads
Posted by Filip Defoort <fi...@cirquedigital.com>.
Hi,
I'm accessing VFS FileObjects from different threads and running into some
synchronization problems (using the ON_RESOLVE cache strategy).
Sometimes, the FileObject gets detached while it's still being used by
another
thread causing exceptions and sometimes the FileObject go into a deadlock.
What are the rules for accessing FileObjects from different threads ?
Many thanks in advance,
- Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[VFS] renaming file with only case differences
Posted by Filip Defoort <fi...@cirquedigital.com>.
Hi,
I'm running in the following problem: VFS doesn't seem to be able to
rename a file to another name when only the case is different. On windows,
since the file system is case insensitive, File.exists() returns true, which
causes FileObject.moveTo() to actually delete the source file (since it's
considered the same file as the target).... that's obviously not
desirable...
Anybody any ideas on how I can do a proper rename ? Would it be better
to have a separeate renameTo method (not moveTo) that would not delete
the target first ?
Thanks in advance!
- Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] setting read-only, hidden, etc
Posted by Andy Lewis <aj...@ascii27.net>.
While I do not actively post on this list or contribute to VFS, I have
used VFS extensively and been trying to start on a project that would
both use it and allow me to contribute. I have given a great deal of
thought to the permissions and have a suggestion. There are two primary
types of permissions models that need to be accounted for, and nearly
everything falls under these. There are UNIX type permissions -
user/group/owner and read/write/execute, and there are Access Control
List based systems, which is what Windows, Solaris, and many other
systems (including some Linux versions) implement.
I would implement these as two completely different sets of discoverable
capabilities. A given file or file system type may support neither,
either, or both. Many systems would never support any, Windows would
support ACL style, Linux would support Unix style, and Solaris may
support both.
A Unix style would have to be able to deal with users and groups as
numerics, and possibly provide an interface for resolving those groups
to names where the information can be obtained for the underlying file
system.
An ACL system would also have groups, group membership, users, a set of
distinct assignable rights, etc. ACL is certainly the more complex
system to implement.
The reality does remain however that some level of native interface will
be required for many of these, but that is an implementation detail that
matters for each specific file system and should not prevent adding a
support framework to VFS. While I haven't looked at what the underlying
library support, it occurs to me that a CIFS system might be the ideal
candidate to use for developing the ACL test case as it should be doable
with no native code.
Note that I would put together something to contribute if I had time.
Since I haven't I wanted to at least throw the results of my thoughts
out for discussions since the topic has come up.
Thanks!
Mario Ivankovits wrote:
> Hi!
>
>> I'm making a prototype of File to VFS adaptor
>> (http://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/util/jio/),
>>
>> which made me realise that there is no support for setting a bunch of
>> stuff like read-only, hidden, etc, that a File does...
>>
>
> These limitation are simply due to the restrictions of the most
> filesystem libraries, they simply do not provide such a mechanism,
> even for local files we have to go the native way to change those
> attributes.
>
>> 2) Deprecate or remove the getters, add a new Service/Action/Operation
>> that allow to get/set that information.
>>
>
> When we deprecate those methods is another story, but to figure out a
> common way how to modify attributes and security constraints will be
> the first challange. Implementing such a stuff as
> Service/Action/Operation at a first step will be great.
> We need to find a way to express the various security systems
> linux/windows using one api.
> I am currently out of time to think about in detail, but maybe
> something like
>
> file owner (with an set of permissions for windows/linux)
> file users (other users with special rights - with an set of
> permissions representable only for windows)
> file usergroups (n groups in windows. only two: group/other in linux)
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] setting read-only, hidden, etc
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> I'm making a prototype of File to VFS adaptor
> (http://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/util/jio/),
> which made me realise that there is no support for setting a bunch of
> stuff like read-only, hidden, etc, that a File does...
>
These limitation are simply due to the restrictions of the most
filesystem libraries, they simply do not provide such a mechanism, even
for local files we have to go the native way to change those attributes.
> 2) Deprecate or remove the getters, add a new Service/Action/Operation
> that allow to get/set that information.
>
When we deprecate those methods is another story, but to figure out a
common way how to modify attributes and security constraints will be the
first challange. Implementing such a stuff as Service/Action/Operation
at a first step will be great.
We need to find a way to express the various security systems
linux/windows using one api.
I am currently out of time to think about in detail, but maybe something
like
file owner (with an set of permissions for windows/linux)
file users (other users with special rights - with an set of permissions
representable only for windows)
file usergroups (n groups in windows. only two: group/other in linux)
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org