public final class FileAccessorLocalJava7 extends FileRemoteAccessor
FileRemote
which uses the java.nio.files startegy (new from Java-7)
| Modifier and Type | Class and Description |
|---|---|
private class |
FileAccessorLocalJava7.RunRefresh
A thread which gets all file properties independent of a caller of the #re
|
(package private) class |
FileAccessorLocalJava7.WalkerThread |
protected class |
FileAccessorLocalJava7.WalkFileTreeVisitor
This class is the general FileVisitor for the adaption layer to FileRemote.
|
FileRemoteAccessor.FileWalkerThread| Modifier and Type | Field and Description |
|---|---|
(package private) EventSource |
evSrc
The state machine for executing over some directory trees is handled in this extra class.
|
(package private) EventConsumer |
executerCommission
Destination for all events which forces actions in the execution thread.
|
private static FileRemoteAccessor |
instance |
static FileRemote.FileRemoteAccessorSelector |
selectLocalFileAlways
Access selector which uses
FileAccessorLocalJava7 for any path. |
(package private) EventTimerThread |
singleThreadForCommission
This thread runs after creation.
|
static java.lang.String |
sVersion
Version, history and license.
|
protected java.lang.Class<? extends java.nio.file.attribute.BasicFileAttributes> |
systemAttribtype
Type of the attributes of files.
|
private static boolean |
useFileChildren
Some experience possible: if true, then store File objects in
FileRemote.children instead
FileRemote objects. |
(package private) FileAccessorLocalJava7.WalkerThread[] |
walkerThread |
private FileRemote |
workingDir
The state machine for executing over some directory trees is handled in this extra class.
|
versionmEventConsumed, mEventConsumerException, mEventConsumFinished, mEventDonotRelinquish, mMaskReservedHere| Modifier | Constructor and Description |
|---|---|
private |
FileAccessorLocalJava7()
Use
getInstance() to get the singleton instance. |
| Modifier and Type | Method and Description |
|---|---|
void |
abortAll()
Abort currently running and saved copy, check etc. actions.
|
void |
activate()
Activates working of the devide, thread starting, communication establishing etc.
|
private boolean |
chgFile(java.io.File dst,
int maskFlags,
int newFlags,
boolean ok) |
private boolean |
chgFile1(java.io.File dst,
int maskFlags,
int newFlags) |
private boolean |
chgPropsRecursive(java.io.File dst,
int maskFlags,
int newFlags,
boolean ok,
int recursion) |
void |
close() |
java.lang.String |
cmd(boolean bWait,
FileRemoteCmdEventData co,
EventWithDst<FileRemoteProgressEvData,?> evBack)
|
java.lang.CharSequence |
completeFilePath(java.lang.CharSequence sPath)
Returns a unique absolute path for the file regarding maybe tmp, home, environment variables etc.
|
void |
copyChecked(FileRemote fileSrc,
java.lang.String pathDst,
java.lang.String nameModification,
int mode,
FileRemoteWalkerCallback callbackUser,
FileRemoteProgressEvData timeOrderProgress)
Copies all files which are checked before.
|
protected static java.lang.String |
copyFile(FileRemoteCmdEventData co,
EventWithDst<FileRemoteProgressEvData,?> evBack) |
private long |
countLengthDir(java.io.File file,
long sum,
int recursion)
Uses the java.io.File
|
boolean |
createNewFile(FileRemote file,
EventWithDst<FileRemoteProgressEvData,?> evBack) |
boolean |
delete(FileRemote file,
EventWithDst<FileRemoteProgressEvData,?> evBack)
Try to delete the file.
|
EventThread_ifc |
evThread()
This operation should return that thread, which is associated to this consumer.
|
private void |
execChgProps(FileRemoteCmdEventData co,
EventWithDst<FileRemoteProgressEvData,?> evBack) |
private void |
execChgPropsRecurs(FileRemoteCmdEventData co,
EventWithDst<FileRemoteProgressEvData,?> evBack) |
protected java.lang.String |
execCmd(FileRemoteCmdEventData co,
EventWithDst<FileRemoteProgressEvData,?> evBack)
This is called in the
FileAccessorLocalJava7.WalkerThread or immediately from cmd(boolean, org.vishia.fileRemote.FileRemoteCmdEventData, EventWithDst)
if first argument is true. |
(package private) int |
execCommission(EventWithDst<FileRemoteCmdEventData,FileRemoteProgressEvData> commission)
Executes the given event as commission.
|
private void |
execCountLength(FileRemoteCmdEventData co,
EventWithDst<FileRemoteProgressEvData,?> evBack) |
(package private) void |
execDel(FileRemoteCmdEventData co,
EventWithDst<FileRemoteProgressEvData,?> evBack)
Executes delete file maybe in an extra thread or really remote
|
void |
finalize() |
java.util.List<java.io.File> |
getChildren(FileRemote file,
java.io.FileFilter filter)
Gets files and sub directories of a directory.
|
static FileRemoteAccessor |
getInstance()
Returns the singleton instance of this class.
|
private java.io.File |
getLocalFile(FileRemote fileRemote) |
java.lang.CharSequence |
getStateInfo() |
boolean |
isLocalFileSystem()
Creates or prepares a CmdEvent to send to the correct destination.
|
boolean |
mkdir(FileRemote dir,
boolean subdirs,
EventWithDst<FileRemoteProgressEvData,?> evBack) |
protected static java.lang.String |
moveFile(FileRemoteCmdEventData co,
EventWithDst<FileRemoteProgressEvData,?> evBack) |
java.io.InputStream |
openInputStream(FileRemote file,
long passPhase)
Creates an InputStream with this fileRemote instance.
|
java.io.OutputStream |
openOutputStream(FileRemote file,
long passPhase)
Creates an OutputStream with this fileRemote instance.
|
java.nio.channels.ReadableByteChannel |
openRead(FileRemote file,
long passPhase) |
java.nio.channels.WritableByteChannel |
openWrite(FileRemote file,
long passPhase) |
int |
processEvent(java.util.EventObject ev)
Processes immediately an event,
but delegate to a free
walkerThread
It means the processing is finished in this thread,
but the event is not relinquished yet immediately. |
void |
refreshFileProperties(FileRemote fileRemote,
EventWithDst<FileRemoteProgressEvData,?> evBack)
Sets the file properties from the existing file on the device.
|
void |
search(FileRemote fileSrc,
byte[] search,
FileRemoteWalkerCallback callbackUser,
FileRemoteProgressEvData timeOrderProgress)
Search in all files.
|
protected static void |
setAttributes(FileRemote fileRemote,
java.nio.file.Path path,
java.nio.file.attribute.BasicFileAttributes attribs)
Sets the real attributs.
|
boolean |
setLastModified(FileRemote file,
long time) |
protected void |
walkFileTreeExecInThisThread(FileRemoteCmdEventData co,
boolean bRefreshChildren,
EventWithDst<FileRemoteProgressEvData,?> evBack,
boolean debugOut)
Executes walk file tree.
|
cmdFilepublic static final java.lang.String sVersion
FileAccessorLocalJava7.WalkFileTreeVisitor.preVisitDirectory(Path, BasicFileAttributes):
If the parent directory is marked with FileMark.cmpAlone and this bit is part of the select mask in the command (commision),
then the directory is marked with FileRemoteCmdEventData.markSet(), means the bits to set for selection.
This allows copy also an alone standing directory. But yet todo it does not copy .... the files internally.
FileAccessorLocalJava7.WalkFileTreeVisitor.visitFile(Path, BasicFileAttributes): Possibility to reset mark bits if the file is non selected.
This is important to clean marking from the.File.commander.
Second: bugfix for comparison files, if cmpTimeGreater or Lesser is set but the files are marked as cmpContentEqual,
then they are not selected if cmpContentNotEqual flag is required
Files.isSymbolicLink(Path) in Java original does not detect a JUNCTION as symbolic link, that is not nice.
The solution is also tested in FileAccessorLocalJava7.WalkFileTreeVisitor.preVisitDirectory(Path, BasicFileAttributes):
With Path.toRealPath(LinkOption...) the path resulting from JUNCTION is detected, and by comparison with Path.toAbsolutePath()
it is detected that this is very probably a JUNCTION.
It is important that also Junctions are not entered if FileMark.ignoreSymbolicLinks is set.
This is firstly for updating and comparison for source file trees. The symbolic linked directories (via Junction) should not be handled then,
because they should be handled in there own working tree"
Also the mode is set from outside, change argument list of FileCallbackLocalCmp.FileCallbackLocalCmp(FileRemote, FileRemote, int, FileRemoteWalkerCallback, EventWithDst).
FileRemoteWalker.WalkInfo instead CurrDirChildren, the content is the same.
delete(FileRemote, EventWithDst) but this is now obsolete.
Improve execDel(org.vishia.fileRemote.FileRemoteCmdEventData, EventWithDst).
WalkInfo is now subclass ot this, used for walkInfo in FileCallbackLocalDelete,
but should be renamed to WalkInfo.
FileAccessorLocalJava7.WalkFileTreeVisitor.preVisitDirectory(Path, BasicFileAttributes) now set the first level always to selected
but does not call callback. The first level is the entry, not to handle for the functionality. See comment there.
Adequate for FileAccessorLocalJava7.WalkFileTreeVisitor.postVisitDirectory(Path, IOException).
execCmd(org.vishia.fileRemote.FileRemoteCmdEventData, EventWithDst) now also with copyFile, moveFile
FileAccessorLocalJava7.WalkFileTreeVisitor.debugOut as helper.
#walkFileTree(FileRemote, boolean, boolean, int, int, String, long, int, FileRemoteWalkerCallback, FileRemoteProgressEvData)
with selection via mask, used for copy of selected files. Additional: mark during walk.
FileAccessorLocalJava7.WalkFileTreeVisitor.postVisitDirectory(Path, IOException)
to allow the graphic thread working.
#walkFileTreeExecInThisThread(FileRemote, boolean, boolean, String, long, int, FileRemoteWalkerCallback, FileRemoteProgressEvData)
is called recursively by org.vishia.fileLocalAccessor.FileCallbackLocalCmp#offerParentNode(FileRemote).
Hence it is bad to set progress.bDone = true; in this operation, it kills the progress visibility
because it sets to bDone after a sub directory. It is shifted to #walkFileTree(FileRemote, boolean, boolean, boolean, String, long, int, FileRemoteWalkerCallback, FileRemoteProgressEvData)
done after really finished.
FileAccessorLocalJava7.WalkFileTreeVisitor.
It was a new feature: check with a duplicated implementation instead refactored implementation. Now it is refactored.
Test: org.vishia.commander.Fcmd runs, org.vishia.fileRemote.test.TestFileRemote used for test.
FileAccessorLocalJava7.WalkFileTreeVisitor.postVisitDirectory(Path, IOException):
The same directory was walked twice because the callback was called firstly. The callback forces a #walkFileTree(FileRemote, boolean, boolean, boolean, String, long, int, FileRemoteWalkerCallback)
started in another thread. This marks all child files with FileRemote.mRefreshChildPending while the other thread has removed the FileRemote child instances
which are marked with that. Therefore FileRemote instances were removed and created new, there are existing more as one for the same file after them.
The order of execution is changed yet only, so the bug is not forced. The core of the bug is a thread safety. While a walkFileTree for a directory runs,
another thread should wait for it or skip it because the other thread refreshes already in the near time.
WalkFileTreeVisitor.WalkInfo is deactivate because not used before.
A seldom error of twice instances for the same children of a directory was watched.
WalkFileTreeVisitor.WalkInfo#children is not used any more, the refreshing of children is done
in the Map instance of FileRemote.children() with marking the children with FileRemote.mRefreshChildPending as flag bit
while refreshing is pending and removing the files which's mark is remain after refresh. With them a new instance of a Map is not necessary.
FileAccessorLocalJava7
private static final boolean useFileChildren
FileRemote.children instead
FileRemote objects. The File objects may be replaces by FileRemote later if necessary. This may be done
in applications. The problem is: Wrapping a File with FileRemote does not change the reference in FileRemote.children
automatically. It should be done by any algorithm. Therefore this compiler switch is set to false yet.private static FileRemoteAccessor instance
protected final java.lang.Class<? extends java.nio.file.attribute.BasicFileAttributes> systemAttribtype
EventSource evSrc
Copy#Copy(FileAccessorLocalJava7) needs initialized references
of singleThreadForCommission and executerCommission.EventTimerThread singleThreadForCommission
final FileAccessorLocalJava7.WalkerThread[] walkerThread
EventConsumer executerCommission
private FileRemote workingDir
Copy#Copy(FileAccessorLocalJava7) needs initialized references
of singleThreadForCommission and executerCommission.public static FileRemote.FileRemoteAccessorSelector selectLocalFileAlways
FileAccessorLocalJava7 for any path.
It is the standard for normal PC programs.private FileAccessorLocalJava7()
getInstance() to get the singleton instance.public void finalize()
finalize in class java.lang.Objectpublic void activate()
FileRemoteAccessoractivate in class FileRemoteAccessorpublic static FileRemoteAccessor getInstance()
public java.lang.CharSequence completeFilePath(java.lang.CharSequence sPath)
FileFunctions.absolutePath(String, File) to fulfill all.completeFilePath in class FileRemoteAccessorpath - given pathprivate java.io.File getLocalFile(FileRemote fileRemote)
protected static void setAttributes(FileRemote fileRemote, java.nio.file.Path path, java.nio.file.attribute.BasicFileAttributes attribs)
fileRemote - path - should be gotten as existing path,attribs - public void refreshFileProperties(FileRemote fileRemote, EventWithDst<FileRemoteProgressEvData,?> evBack)
FileRemote.mTested flag any time.
If the file exists, the properties of the file were set, elsewhere they were set to 0.
refreshFileProperties in class FileRemoteAccessorfileRemote - the destination file object.org.vishia.fileRemote.FileRemoteAccessor#refreshFileProperties(org.vishia.fileRemote.FileRemote)}public java.util.List<java.io.File> getChildren(FileRemote file, java.io.FileFilter filter)
FileRemoteAccessorFile access methods to get the children of this file.getChildren in class FileRemoteAccessorfile - parent directory.filter - maybe a filterpublic boolean setLastModified(FileRemote file, long time)
setLastModified in class FileRemoteAccessorpublic java.nio.channels.ReadableByteChannel openRead(FileRemote file, long passPhase)
openRead in class FileRemoteAccessorpublic java.io.InputStream openInputStream(FileRemote file, long passPhase)
FileRemoteAccessoropenInputStream in class FileRemoteAccessorpublic java.io.OutputStream openOutputStream(FileRemote file, long passPhase)
FileRemoteAccessoropenOutputStream in class FileRemoteAccessorpublic java.nio.channels.WritableByteChannel openWrite(FileRemote file, long passPhase)
openWrite in class FileRemoteAccessorpublic boolean createNewFile(FileRemote file, EventWithDst<FileRemoteProgressEvData,?> evBack) throws java.io.IOException
createNewFile in class FileRemoteAccessorjava.io.IOExceptionpublic boolean mkdir(FileRemote dir, boolean subdirs, EventWithDst<FileRemoteProgressEvData,?> evBack)
mkdir in class FileRemoteAccessorsubdirs - true then create all necessary dirs on the pathevBack - It will be called on any directory which was made, to update the local instance of FileRemote.public boolean delete(FileRemote file, EventWithDst<FileRemoteProgressEvData,?> evBack)
FileRemoteAccessordelete in class FileRemoteAccessorpublic void copyChecked(FileRemote fileSrc, java.lang.String pathDst, java.lang.String nameModification, int mode, FileRemoteWalkerCallback callbackUser, FileRemoteProgressEvData timeOrderProgress)
FileRemoteAccessorcopyChecked in class FileRemoteAccessorfileSrc - dir or file as root for copy to the given pathDstpathDst - String given destination for the copynameModification - Modification for each name. null then no modification. TODOmode - One of the bits FileRemote.modeCopyCreateYes etc.callbackUser - Maybe null, elsewhere on every directory and file which is finished to copy a callback is invoked.timeOrderProgress - may be null, to show the progress of copy.protected static java.lang.String copyFile(FileRemoteCmdEventData co, EventWithDst<FileRemoteProgressEvData,?> evBack)
protected static java.lang.String moveFile(FileRemoteCmdEventData co, EventWithDst<FileRemoteProgressEvData,?> evBack)
public void search(FileRemote fileSrc, byte[] search, FileRemoteWalkerCallback callbackUser, FileRemoteProgressEvData timeOrderProgress)
FileRemoteAccessorsearch in class FileRemoteAccessorfileSrc - dir or file as root for search the given byte[]callbackUser - Maybe null, elsewhere on every directory and file which is finished to copy a callback is invoked.timeOrderProgress - may be null, to show the progress of copy.public boolean isLocalFileSystem()
FileRemoteAccessorisLocalFileSystem in class FileRemoteAccessorpublic java.lang.CharSequence getStateInfo()
getStateInfo in class FileRemoteAccessorpublic void abortAll()
FileRemoteAccessorabortAll in class FileRemoteAccessorint execCommission(EventWithDst<FileRemoteCmdEventData,FileRemoteProgressEvData> commission)
commission - StateSimple,
especially from here StateSimple#mEventConsumed and StateSimple#mEventDonotRelinquish.
The last one is identically with EventConsumer.mEventDonotRelinquish
and is set, if this event is forwarded to the #theThreaad of this state machine.protected java.lang.String execCmd(FileRemoteCmdEventData co, EventWithDst<FileRemoteProgressEvData,?> evBack)
FileAccessorLocalJava7.WalkerThread or immediately from cmd(boolean, org.vishia.fileRemote.FileRemoteCmdEventData, EventWithDst)
if first argument is true.co - evBack - public java.lang.String cmd(boolean bWait,
FileRemoteCmdEventData co,
EventWithDst<FileRemoteProgressEvData,?> evBack)
FileRemoteAccessor.cmd(boolean, org.vishia.fileRemote.FileRemoteCmdEventData, EventWithDst).
Hint: Set breakpoint to execCmd(org.vishia.fileRemote.FileRemoteCmdEventData, EventWithDst)
to stop in the execution thread.cmd in class FileRemoteAccessorbWait - true then wait for fulfill. If it is a local file (depends on FileRemote.device(),
then the execution is immediately done in the same thread.
If it is especially a file on a remote device only able to reach via communication
( for example on an embedded device), the operation should wait for success.co - Command description. It is the payload of an command event.evBack - prepared event for back information or also for progress.
The event knows a destination where the back event is processed.
If this argument is null, no back information will be sent. This is sensible if bWait is true,
and if the caller can check what is happen.
Hint: Usual an instance of FileRemoteProgressEventConsumer can be used to execute the event,
and also to wait for success on user level.private void execChgProps(FileRemoteCmdEventData co, EventWithDst<FileRemoteProgressEvData,?> evBack)
private void execChgPropsRecurs(FileRemoteCmdEventData co, EventWithDst<FileRemoteProgressEvData,?> evBack)
private boolean chgPropsRecursive(java.io.File dst,
int maskFlags,
int newFlags,
boolean ok,
int recursion)
private boolean chgFile(java.io.File dst,
int maskFlags,
int newFlags,
boolean ok)
private boolean chgFile1(java.io.File dst,
int maskFlags,
int newFlags)
private void execCountLength(FileRemoteCmdEventData co, EventWithDst<FileRemoteProgressEvData,?> evBack)
private long countLengthDir(java.io.File file,
long sum,
int recursion)
file - sum - recursion - void execDel(FileRemoteCmdEventData co, EventWithDst<FileRemoteProgressEvData,?> evBack)
co - evBack - public void close()
close in class FileRemoteAccessorprotected void walkFileTreeExecInThisThread(FileRemoteCmdEventData co, boolean bRefreshChildren, EventWithDst<FileRemoteProgressEvData,?> evBack, boolean debugOut)
execCmd(org.vishia.fileRemote.FileRemoteCmdEventData, EventWithDst)
either in one of the FileAccessorLocalJava7.WalkerThread or immediately in the caller thread.co - data what should be done, especially FileRemoteCmdEventData.callback describes what should be done with a file.bRefreshChildren - true then reads the properties of all children from the original file system.evBack - a progress event, also usable for quests with answer via the EventWithDst.getOpponent() prepared before call.debugOut - public EventThread_ifc evThread()
EventConsumerprocessEvent(EventObject)public int processEvent(java.util.EventObject ev)
walkerThread
It means the processing is finished in this thread,
but the event is not relinquished yet immediately.ev - The event. It contains some data. The type of the event is not specified here. Any events
can be processed.EventConsumer.mEventConsumed or EventConsumer.mEventDonotRelinquish etc. see list above.
This value is forwarded to EventSource.notifyConsumed(int) and can be evaluated by the application
in the calling thread or in any other thread which have access to implementation of EventSource.