orestis-alex / dokan

Automatically exported from code.google.com/p/dokan
0 stars 0 forks source link

MoveFile via a share does not have the correct rename FilePathName #238

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Start Mirror
2. Create a share to the subdirectory
3. Connect to the share
4. Attempt to rename a file
5. Observe what the MoveFileProxy has been sent, and what action was requested.

What is the expected output? 
- The action is to rename "New Text Document.txt" to "Test.txt" in the same 
directory
- MoveFileProxy replaceIfExisting [0] file: [\Test1\ds\ds\New Text 
Document.txt] newfile: [\Test1\ds\ds\test.txt] 

What do you see instead?
- It can be seen that there are now 2 extra directories added into the 
directory path
- The share was to "\Test1"
- MoveFileProxy replaceIfExisting [0] file: [\Test1\ds\ds\New Text 
Document.txt] newfile: [\Test1\ds\ds\ds\ds\test.txt] 

What version of the product are you using? 
- 0.6.0
- Mirror.Net

On what operating system?
- Win 7 x64 as host
- Win 8 x64 as client

Please provide any additional information below.
[http://liquesce.codeplex.com/workitem/9828]

Proxy Code is:
public int MoveFileProxy(IntPtr rawFileName, IntPtr rawNewFileName, int 
rawReplaceIfExisting, ref DOKAN_FILE_INFO rawFileInfo)
{
  try
  {
    string file = GetFileName(rawFileName);
    string newfile = GetFileName(rawNewFileName);
    Log.Trace("MoveFileProxy replaceIfExisting [{0}] file: [{1}] newfile: [{2}]", rawReplaceIfExisting, file, newfile);

Original issue reported on code.google.com by smurf...@gmail.com on 17 Nov 2011 at 4:52

GoogleCodeExporter commented 9 years ago
The Function "DokanSetRenameInformation" from inside 
[http://code.google.com/p/dokan/source/browse/trunk/dokan/setfile.c] looks very 
suspect when it performs the copy of the old file-name path into the beginning 
of the buffer.
If it does not have a beginning '\', then perhaps this is something to do with 
SMB redirection, and "can / should" be handled by the user space implementation 
(i.e. through documentation and an example!)

Original comment by smurf...@gmail.com on 17 Nov 2011 at 5:44

GoogleCodeExporter commented 9 years ago
FYI
C# workaround that will be going into Liquesce:
[Where info is the converted DOKAN_FILE_INFO]

if (ProcessIdentity.CouldBeSMB(info.ProcessId)
  && (600 == Dokan.DokanVersion())
  )
  {
   Log.Warn("ProcessID indicates that this could be an SMB redirect. Workaround dokan issue 238!");
   int lastIndex = oldName.LastIndexOf(Roots.PathDirectorySeparatorChar);
   string offsetPath = (lastIndex > -1) ? newName.Remove(0,lastIndex+1) : newName;
   pathTarget = roots.GetPathRelatedtoShare(offsetPath, (ulong)pathSource.Length);
  }
  else
  {
   // Now check to see if this has enough space to make a "Copy" before the atomic delete of MoveFileEX
   pathTarget = roots.GetPath(newName, (ulong) pathSource.Length);
  }

Original comment by smurf...@gmail.com on 17 Nov 2011 at 7:09

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
?? If this is going from XP to an XP client then the issue above is not 
triggered ??

Original comment by smurf...@gmail.com on 7 Jun 2012 at 5:34