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.

Bug 10145 - Need an API to disable cut/delete/rename actions for a selected fileobject in the VCS filesystem
Summary: Need an API to disable cut/delete/rename actions for a selected fileobject in...
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Nodes (show other bugs)
Version: 3.x
Hardware: Sun Solaris
: P3 blocker (vote)
Assignee: t_h
URL:
Keywords:
Depends on: 18177
Blocks: 22143 17795
  Show dependency tree
 
Reported: 2001-03-09 22:30 UTC by Sadhana Rau
Modified: 2008-12-22 09:50 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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
kartik.mithal@sun.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?