This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Summary:||Need an API to disable cut/delete/rename actions for a selected fileobject in the VCS filesystem|
|Product:||platform||Reporter:||Sadhana Rau <sadhana>|
|Severity:||blocker||CC:||asunhachawee, mentlicher, sdeng, tstupka|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:||18177|
|Bug Blocks:||22143, 17795|
Description Sadhana Rau 2001-03-09 22:30:42 UTC
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 AbstractFileSystem.Change interfaces filesystem can define filesystem specific cut/delete behavior. So filesystem can disallow the action if not supported for that filesystem. 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 TeamWareFileSystem] Thanks, Sadhana
Comment 1 Martin Entlicher 2001-03-12 10:14:51 UTC
This would need some support from Open API. Therefore reassigning the issue there.
Comment 2 Jaroslav Tulach 2001-03-13 09:46:35 UTC
Why the regular delete/rename cannot not work? IMHO it should be supported, it would be consistent with the rest of the ide.
Comment 3 Jaroslav Tulach 2001-03-13 09:49:00 UTC
Really can't see a reason why delete/rename should not work.
Comment 4 Ann Sunhachawee 2001-03-13 18:31:39 UTC
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.
Comment 5 Kartik Mithal 2001-03-24 05:02:01 UTC
Jarda, please elaborate on why you have marked this as invalid. It sounds like a reasonable reuest. thanks, Kartik email@example.com
Comment 6 Sadhana Rau 2001-03-27 19:10:08 UTC
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 : isRenameAllowed isCopyAllowed isMoveAllowed isDeleteAllowed 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. Thanks, Sadhana
Comment 7 Jaroslav Tulach 2001-04-09 18:17:48 UTC
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 nbdev.
Comment 8 Sadhana Rau 2001-04-11 19:08:20 UTC
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.
Comment 9 Jan Chalupa 2001-05-06 08:13:21 UTC
Target milestone -> 3.3
Comment 10 Jaroslav Tulach 2001-10-08 11:59:36 UTC
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) problem. 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.
Comment 11 Jan Chalupa 2001-11-27 13:03:40 UTC
Target milestone -> 3.3.1.
Comment 12 David Strupl 2002-01-28 14:19:53 UTC
Assigned to 17597 owner ...
Comment 13 Jaroslav Tulach 2002-01-29 08:54:02 UTC
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.
Comment 14 David Simonek 2002-01-29 13:26:37 UTC
Reassigning, looks and nodes are out of my responsibility at this time.
Comment 15 David Simonek 2002-02-05 14:15:06 UTC
Changing target to 4.0, due to dependency on looks.
Comment 16 Jiri Rechtacek 2002-07-22 15:38:50 UTC
change subcomponent to nodes.
Comment 17 Petr Nejedly 2004-01-09 09:45:06 UTC
Taking over the node bugs from phrebejk.
Comment 18 Antonin Nebuzelsky 2008-02-08 15:06:45 UTC
Reassigning to new module owner Tomas Holy.
Comment 19 t_h 2008-10-13 14:46:34 UTC
I guess new VCS support does not need it, right?