The question is regarding the cut/delete/rename behavior
of the files in the filesystem
and how the filesystem can influence it.
I know that by implementing AbstractFileSystem.Tranfer and
interfaces filesystem can define filesystem specific
So filesystem can disallow the action if not supported for
I would like an API so that filesystem can disable these actions
for certain files based on their vcs status.
e.g. I would like to disable cut/delete/rename for the files that are
in the VCS repository even if their writable clear files exist in the directory.
For VCS files, I want to disallow cut/delete/rename and want user to use
VCS provided delete and rename.
[Background : I am extending VcsFileSystem to provide
This would need some support from Open API. Therefore reassigning the issue
Why the regular delete/rename cannot not work? IMHO it should be supported, it
would be consistent with the rest of the ide.
Really can't see a reason why delete/rename should not work.
In TeamWare, there is a notion of the "history file" for each file that is put
under version control. It becomes problematic when we try to have the regular
IDE functions (such as Cut/Delete/Rename/Paste) apply to these files under
version control. For example - Does Cut/Delete try to cut just the clear file,
or should it remove the entire history file as well?
We decided that overloading these IDE functionalities may result in dangerous
situations for the user since they might not know what the implications of their
actions are. Sure, we could pop up a warning dialog "Your history file will be
deleted", though this would most likely not be read. so we would rather them use
the explicit TeamWare commands to do the "Rename", "Delete from TeamWare", or
"Move file(s) and history".
So, this is our reasoning for not wanting to enable Cut/Delete/Rename. I don't
think this is an invalid request. Please reconsider this. Thanks.
please elaborate on why you have marked this as invalid. It sounds like a
Here is an example of why I need to disable cut/paste for my filesystem.
Cut/paste action implies moving files around.
For TeamWare FileSystem (aka TeamWare workspace) moving files within the same
workspace is allowed but across TeamWare workspaces and outside the workspace
is not allowed. Files are transferred between workspaces via the workspace
transactions like bringover and putback.
In this case, to correctly support this model for the user, I need disable
cut/paste for the TeamWare file system.
Looking at the current APIs, we have following APIs for DataObject :
But the logic of these only consults FileSystem for FileObject's file
permissions and FileSystem's status e,g, readOnly file system etc.
Then decides for itself if the operations are allowed.
FileSystem is not given a chance to decide if the operation is allowed for
a given FileObject.
Can we improve the support so that filesystem can override the default logic
if it wants to.
Sorry for my delay, I tried to fix as much for 3.2 as possible...
Why the moving of file out from workspace does not mean to delete it on the
workspace (which would not be really done until next putback)?
Anyway, I would like to hit bigger audience, I will write about this problem to
Please also refer to issue# 11237, seems like I cannot even properly overload
the move (cut and paste) action between two file systems.
Currently my filesystem.transfer.move implementation , only
supports moving files within the same filesystem. For my filesystem in
addition to moving the clear file , I also move the history file. So I have to
provide my own implementation of move method and cannot use the default
implementation , by returning false.
Target milestone -> 3.3
Everytime I think about the problem I feel that this is not issue in
communication between FS & DataObject, but FS & Explorer. The
filesystem can have different expectation and add-ons for behaviour of
explorer (new paste types, etc.) and I guess that allowing some hooks
in explorer is the right way how to solve this (and a lot of others)
Explorer API should introduce an "controler" interface to allow
anybody else to plug in its own implementation and modify the set of
enabled actions, paste types, etc.
Note: The change should be probably done in cooperation with rewrite
of Action API.
Target milestone -> 3.3.1.
Assigned to 17597 owner ...
Guys, this issue can be solved by using Looks API (special nodes for
objects on VCS FileSystem). So let this depend on issue 18177 and
finish looks API before we go on solving this issue.
Reassigning, looks and nodes are out of my responsibility at this time.
Changing target to 4.0, due to dependency on looks.
change subcomponent to nodes.
Taking over the node bugs from phrebejk.
Reassigning to new module owner Tomas Holy.
I guess new VCS support does not need it, right?