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.
I am trying to fix a bug in my module which provides a VCS file system imple- mentation. (say MyFileSystem) The bug is that IDE throws FileStateInvalidException (in AbstractFileObject.copy) when user tries to copy a file from one of the mounted MyFileSystem to another. I have traced the problem back to the following API : AbstractFileSystem.copy (String old, AbstractFileSystem.Transfer target, String new) where old is the filename(relative to its Filesystem rootdir) of the file to be copied, target is the Transfer object for the FileSystem to which file needs to be copied to, new if the filename (relative to its filesystem root) (old comes from filesystem from where file is copied from, new comes from filesystem where the file will be copied to) in MyFileSystem.Transfer.copy() implementation I need to copy a "old" file from one file system to another with "new" name, but I don't have access to the root directory of the Filesystem to which to file the file. So basically I cannot provide copying files from one of my mounted filesystem to another. I don't know how to use the Transfer object passed in as a parameter. I propose following API for AbstractFileSystem.Transfer.copy(String, AbstractFileSystem, String)
Also the same problem exist for move method in AbstractFileSystem.Transfer interface.
I took in that you have problem with implementation of Transfer on your subclass of AbstracFileSystem. In org.openide.filesystems there exists no subclass of AbstracFileSystem that would implement Transfer interface. So if you want to interchange FileObjects between two filesystems (that are both subclassed of AbstractFileSystem and implement Transfer iface) then there must be implemented some protocol between these two Transfers. I think that suggested change in API is not necessary.
From your comments I can see that I can support FilleObject transfers between two filesystems where these two file systems are supplied by me and I know the protocol. e.g. if both filesystems are TeamWareFileSystems, then my transfer object can have a protocol to retrieve the root dir of the filesystem. But what if the FileObject is tranferred between two different types of FileSystems e.g. From TeamWareFileSystem to LocalFileSystem? There is no agreed upon protocol between transfer objects of these two filesystems? How do I support that?
Should Transfer interface have that additional protocol method as well. Otherwise how can I guarantee that any given FileSystem implements the protocol in its Transfer object.
Definitely this issue should not affect release 3.2 (only P1 and P2 - must be approved). Moreover this bug should be entered as enhancement. Such enhancement could be discussed on openide or nbdev mailing lists (because of openAPI change). My point of view: 1/ There already exists common protocol for all filesystems - what`s standard behaviour - without need of Transfer interface . 2/ Transfer interface was intended to solve situations that require special handling of move or copy. Transfer protocol can be considered here as proprietary protocol (not common for all others) 3/ Moreover Transfer is interface - should not be extended (it could cause problems with back compatibility) 4/ If there were Transfer interface with some general protocol then it would not help enough. Any of known FileSystems doesn`t implement Transfer protocol. Perhaps I don`t know problems you must face. Is there really no way how to achieve your goal without changing API ? Do you have some arguments that could be used for discussion about this change ?
Sorry to jump into your discussion. I would like to comment following: "There is no agreed upon protocol between transfer objects of these two filesystems?" No, there is no such protocol. How it should look like? What it would be useful for? "But what if the FileObject is tranferred between two different types of FileSystems e.g. From TeamWareFileSystem to LocalFileSystem? Then it is just copied. What else should happen? LocalFS does not offer any special behaviour on copy or move.
There is also opened one enhancement that relates to this one: http://www.netbeans.org/issues/show_bug.cgi?id=11495.
My comments for Yarda's questions : In summary I agree with his comments. >>"There is no agreed upon protocol between transfer objects of these two >>filesystems?" >No, there is no such protocol. How it should look like? What it would be useful for? Alright I really don't have to have a protocol between Transfer objects from different filesystem types. But I still need to create additional method in my Transfer object, to get the filesystem root dir. Then when I am asked to move the file, I have to first check if the Transfer is "instanceof" TeamWareFileSystem.Transfer object, if so, then check the target filesystem root dir and based on that move the VCS file which involves moving the history file in addition to the clear file. >>"But what if the FileObject is tranferred between two different types of >>FileSystems e.g. From TeamWareFileSystem to LocalFileSystem? >>Then it is just copied. What else should happen? LocalFS does not offer any >>special behaviour on copy or move. That right. When a VCS file is moved from TeamWareFileSystem to LocalFileSystem, moving just the clear file makes sense. But if I wanted to move also the history file with the clear file, I cannot as I don't know the target dir.
Discussion on nbdev didn`t prove any interest to change this interface. This bug was recommended to close. There was opinion that history file should not be transfered as part of FileObject.copy method invocation.
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.