Please fix crazy file copy/move: Move leaves empty folders behind RRS feed

  • Question


    Felt like popping this question - been using Vista for a few years now. But annoyed by this - it takes too long to deal with management of the file system.


    When moving files - actually a part of a file hierarchy - often file copy/move in Explorer will leave a empty folders behind ...


    You can then go back and move the rest or left overs to the same destination again


    ... finally when you have done this over and over you will have ended up moving all the files ...


    ... at the end there may be some empty folders left back ...


    ... you can then again check the left overs of the source folders to be moved to see if they are really empty and from there may be delete them to help the "move" command finalizing its work ...


    ... or keep redoing the above process untill everything is moved


    Anybody know what's the case with this - or if am doing something wrong here? Its not a new problem for me - simply felt like popping the question since this goes on and on - without being fixed - that you have to go back and be reassured everything was moved - and usually you have to repeat the "move" command a few times to do a complete move.


    File/folder move - including a file hierarchy is a concept of one transaction I would think.


    There must be a case here since the file copy/move command can not complete its work. No Vista patch has fixed this.


    MS needs to look into the file copy (move) system again since its one of the most basic utilities while it keep doing its work inconsistently (does not complete its work + "slow performance" symptoms: really the notorious estimations of i.e. 52 hours for thousands of file however only totalling 50-150 mb. And it will take seveal minutes like 20 min to move those 50 mb as it suddenly finishes. Break and repeat the command and it may take only less than a minute. Do 1 gig file and it warps only into seconds).


    So it has to work "completely". Currently this command is too demanding to work and collaborate with - its like a crazy colleague.


    As MS has fixed a many important problems. So now this one is getting close to be singled out as one the most important problems to be fixed I think - at least for IT Pros. I also expect that MS will fix it. They always do.

    Sunday, September 14, 2008 3:50 PM

All replies

  • Here are some more former and recent references to "left behind empty folders" when moving files ... anoying


    (because you have to check that they are actually empty folders and deal with it ... you also loose trust in this function to perform correctly ... I have also experienced that sometimes there may even be a file or several more files left behind ... so you can not simply delete the left overs as merely "empy folders" ... bascially impression is that move files operation does not work in the UI):















    Sunday, September 14, 2008 8:06 PM
  • So can someone from MS please respond on what the issue may be - if this is not MS to fix ?


    In any case the end user experience is that the file system operations in the UI does not work when moving files (and btw file copy still outstanding and exceptionally anoying) when using Explorer).


    But I would like someone to elaborate on the first issue - moving files or actually a part of a file hierarchy leaves empty folders behind and occasinally also some files behind?


    Any reasons? Its going beyond me - except this is a bug or strange behaviour that has been allowed to be in Explorer for almost 2 years now.

    Sunday, September 14, 2008 8:09 PM

    Another thing worth while looking beyond the empty folders themselves ??? ... is the sometimes left over files ... in some cases the new "file copy" move behaviour leaves back files that have too long file names (the 255 characther restriction for the entire path). But that seems to be just one case. In this case though when you move the file hierarchy across the same volume a technical detail will make it work however because you can simply do a permutation (file copy code optimization) for the file allocation table to effectively move the hierarchy (so the algorithm does not actually traverse the file hierarchy and does "a block" on some too long file names).


    However, MS need to describe the differences in behaviour for the file copy/move. As a matter of fact it works inconsisently or behaves unreliable because technical details may affect its behaviour. So its hard to let it take responsibility for doing the move effectively. For instance it could report files it could not move.


    In the 255 character case, I suggest you get rid of the 255 constraint due to variability on the actual path length. I have suggested this before. There are several entry points today into a file hierarchy and the OS, especially Vista, makes use of this itself, i.e. for backward compat with documents and settings in XP. Not to take about DFS, Shares, Volumes, Drive Paths, Symbolic Links etc.


    In the case of too long file names it is appalling that the constraint keeps sticking with Windows. Get rid of it in NTFS for Windows 7 (guess it will because of WinFS and SQL Server coming along - so a different file system - so understand that you may be do not want to invest in solving this right now - because it can probalby not be solved that easily ... compatibility horrorfying scenarios as the file system mutates into something for instance XP would not be able to deal with. Also what about FAT32 and external disk drive, USB, flash cards and/or filename/path truncation). And with Windows as the main consumer system ... it has to be automatically managed with respect to NTFS capabilities for actual longer names.


    However still, please answer the question about the empty folders remainin after file moves and in other caes why some files may stil be haning around in the source location if you know why this may happen.



    Sunday, September 14, 2008 10:51 PM

    Another thing is when moving out of a zip file. Is this transactional? Does it copy all out and then delete afterwoods - or does it do the move on a one-by-one basis to keep transactional control?


    Or does move out of zip-files work with Longhorns transactional file system - so it can completely copy out and then delete afterwards and in case of a system failure rely on the transactional file system?


    Does the transactional file system have something to do with the file copy/move behaviour - guess so in some cases.


    Please write and publish an article on the file copy/move behaviour in Longhorn including interdependcies to i.e. the transactional file system - or if article already there point to it (technet, blogs).


    For the case of too long file names another idea is to have a utility that will validate the file system paths to help maintain an invariant of 255 from any path - at least when tested locally. A tool could additionally help maintain it. If cool it could also suggest - as a kind of solution accelerator - new entry points in conjunction with DFS - restricting the depth of the hierarchy while this way also optimizing for network redirector performance (SMB report back on the server side).


    Such a utility/tool seems to me just as important to have for NTFS as defrag, chkdsk (not that important now since transactional NTFS  - very and impressively reliable), file backup (recovery) and other similar basic file system/storage tools. It should also be able to schedule.

    Sunday, September 14, 2008 11:05 PM
  • I am also experiencing this problem since my first boot in Vista. I think this problem is related only to NTFS disks (maybe file security).
    Especially if you try to move folders and replace/merge existing ones. Anyway still nothing found yet.
    Wednesday, October 15, 2008 1:41 PM
  • i agree, vista is unbelievable....i can't even copy a folder from one place to another, or delete a folder.... and the error message gives no explanation or help or workaround. from trolling the web, is seems there is a length restriction on the file path?!?!? how can it install stuff into a path, and then if i try to copy it, it cannot?!?!

    for those of you who still are so loyal to continue using vista, here is what i did before replacing vista with ubuntu....
     - you can use command prompt style copying, i used apache ant script to copy or delete the files
     - you can spend hours delving down into the paths that are too long, then move them to the c:\ so they are shorter, then copy them carefully back into the right spots, or delete them....

    Tuesday, February 17, 2009 11:43 PM