Community
Participate
Working Groups
As per bug 165171 comment 2, RSE does not preserve file permissions when copying files or folders on some remote systems: * ssh SftpFileService does "cp -Rp" so it preserves permissions * dstore UniversalFileSystemMiner does "cp -r" on UNIX so it doesn't preserve does "xcopy /S /E /K /O /Q /H /I" on Windows so /K /O does preserve does plain "cp" or "copy" for single files so this doesn't preserve * local LocalFileService does "cp -r" on UNIX so it doesn't preserve does "xcopy /S /E /K /Q /H /I" on Windows so /K preserves some does plain "cp" or "copy" for single files so this doesn't preserve * for ftp RNFR/RNTO I'm not sure but I guess it keeps permissions * For copying across different hosts, - permission bits are always reset in the normal case - may be kept when "supertransfer" is enabled in Preferences:Files, so the tree is transferred as ZIP or TAR archive. This currently works for dstore only. Semantics should be unified. As per bug 165171 comment 3, Larry England thinks that if possible, we should retain the permissions upon copying independent of copying a single file or a directory structure. When copying across systems, permissions should be honored especially when copying to/from like systems. This would mean that * DStore and Local on UNIX need to use "cp -Rp" for directories and "cp -p" for files * Local on Windows needs to use "xcopy /S /E /K /O /Q /H /I" for directories and "xcopy /K /O /Q /H" for files * For copying across systems, either Supertransfer should be enabled whenever possible, or we need added API to read permissions from the source system and set them on the target system. This may be problematic when copying e.g. from Windows to UNIX which support different styles of permission bits. I think the best solution would be that - Each system type registers the kinds of supertransfer that it supports - During Copy, a "handshake" is done between source and target in order to come up with a common kind of supertransfer that both support - If a common supertransfer is found, permissions can be retained. This proposal is covered in bug 165890. Note that on some UNIX systems, "cp -p" may fail when ACLs are used and the target file system does not support ACLs. I wonder if we should allow a fallback in this case that just shows a warning to the user but still copies the file or tree.
Dave's -- do you see any problem with using modified copy commands as suggested (especially, switching to "cp -p") for dstore and local? If no, can we fix this for 1.0.1?
I don't see any problem with using the modified copy commands as suggested. Copies within the host should be safe enough while the cross-system stuff is a little more complicated. I wonder if it would make sense to divide this into 2 defects - one for copy and a 2nd one for cross-system transfer.
Created bug 166473 for covering the cross-system transfer case. This bug will be used for preserving permissions when copying inside the same system, this should be fixed for 1.0.1 by modifying "cp" and "xcopy" switches as indicated for dstore and local.
for the windows local file copy, the suggested xcopy issues a prompt for whether the destination is a directory or a file. I don't know of an "xcopy" option to surpress this prompt. The "copy" command avoids this - not sure what to do if we have to use xopy in this case.
Option a) new File("tgt").createNewFile(); Runtime.getRuntime().exec("xcopy /Y src tgt"); Option b) Process p = Runtime.getRuntime().exec("xcopy src tgt"); p.getInputStream().println("F"); I prefer option (a) since b might have problems on localized versions of windows that expect characters other than "F" or "D".
Only problem with option (a) is that, in some cases (i.e. copy-rename), the tgt filename will be different from the src filename. So I guess that leaves (b). Are there any cases where "F" and "D" would be unacceptable?
(a) works fine also when tgt filename is different than src filename - I tested it on the commandline touch src touch tgt xcopy /Y src tgt
The windows local, windows remote, unix local and unix remote cases are now handled. For the cross system transfer stuff, now refer to bug 166473.
The read-only property does not seem to be copied on Windows Local.
DaveM can you check? We should really have this consistent for 1.0.1
Okay, looks like the problem is that when we create the new file before the xcopy, the permissions stay as they were at the time of the File.createNewFile(). The createNewFile() call is required to avoid the prompting as to whether the target is the file or a directory ("F" or "D"). I could explicitly deal with the readonly and last modified aspects of this via java.io.File APIs although I'm sure there wouild be some things missed.
Dave - this is not correct. I tried it on a command prompt: I:\tmp>attrib wiki_backup.txt A R I:\tmp\wiki_backup.txt I:\tmp>touch x.x I:\tmp>attrib x.x A I:\tmp\x.x I:\tmp>xcopy /Y /K /O /Q /H wiki_backup.txt x.x 1 File(s) copied I:\tmp>attrib x.x A R I:\tmp\x.x Apparently, the xcopy call DID set the +R attribute on the target file. The problem must be something else.
The problem is worst than first expected. Seems that the xcopy command isn't working - i.e. the copy is failing. The same commmand seems fine from the shell so I'm not sure why this is happening. Will have to look into that deeper.
Problem is that, in special char transformation, we're adding additional \\ characters and xcopy doesn't handle that.
Changing to the following: protected boolean isSpecialChar(char c) { if ((c == '$') || (c == '`') || (c == '"') || (!isWindows() && (c == '\\')) ) { return true; } else { return false; } } I'm adding the !isWindows() check there so that we can preserve the initial file separator - on windows \\ is not allowed in filenames. This change gets the copy working again and the permissions are handled properly via xcopy.
I've committed the change for this and verified that dstore windows didn't have this problem.
Verified Local copy for files and folders on both Windows and Linux. File permissions seem to be copied ok.
Did you check dstore earlier? If yes feel free to set VERIFIED
Yes, but I tested again. Marking bug as verified.
closing.
