Jump to content

jtc

Members
  • Posts

    3
  • Joined

  • Last visited

  • Days Won

    1

jtc last won the day on September 30 2021

jtc had the most liked content!

jtc's Achievements

  1. jtc

    Unremovable nested folders

    Solved (Knock on wood,) Thanks to everyone for the prompt suggestions. For future reference, the list below contains commonly advised methods to delete stuck files when a space has been appended to the file names. Use quotes that enclose the trailing space: rd "my folder " Same as above, but add a trailing [back]slash: rd "my folder \" Try using <shift>+delete to bypass the recycle bin, as suggested by otispresley Specify the UNC path: rd "\\.\C:\temp\my folder " Try 8.3 names (if enabled): rd myfold~1 Finally, boot a Linux Live CD: rmdir "/media/blahblah/temp/my folder " What worked for me: I first uninstalled Dropbox, just in case there was some interaction as Christopher suggested. (I have a vague recollection that the troublesome folders were,in fact, related to a Dropbox incident.) Next, I launched an administrative command prompt and traversed the PoolPart folder on each of the two drives, one drive containing the original and the other the duplicated copy of the intransigent folders. Finally, after trying the UNC path solution and the Shift-Delete method with no success, I tried the second of the ideas listed above, adding a trailing backslash to the "shellext " folder name that was causing all the trouble. ( RD "shellext \" ) It worked. Once done, the remainder of the folder structure was removed with RD /S FIXME, "fixme" being the first-level folder. The errant folders have also disappeared from the DrivePool virtual disk, which did not happen when I had tried a Linux Live CD on my previous attempt. Anyway, thanks again.
  2. I have 4 identical drives, each 3TB, pooled under Drivepool on Windows 10. All pool files are duplicated. There is a "stuck" nested folder structure which is duplicated on two of the drives, and which appears in the Drivepool virtual disk directory (Drive I:, in my case.). The stuck folders cannot be deleted under Windows or within the DrivePool virtual disk. The folder structure is 10 levels deep culminating in "shellext ". In other words "M:\fixme\T2\T3\T4\....T9\shellext ". I cannot recall how I managed to create this originally, but after shortening all the subfolder names and trying every Windows trick on the Internet, I was unsuccessful at deleting it. There is a space appended to "shellext " that is presumably preventing deletion, and all attempts to rename this file/folder have failed. The one trick that worked was booting a live Linux disk and deleting the duplicated structures on disks M: and J: where I found them. However, after rebooting to Windows, the deleted items are restored after a period of time, and I'm back where I started. When I try to delete the folders directly or in DrivePool, the error message is (and always has been) "Could not find this item." Is DrivePool contributing to this problem, or causing the restoration of the deleted folder structure? Any ideas on how to fix? The problem isn't fatal, but it is an annoyance. .
  3. I've been running DrivePool 2.2.0.651, and Stablebit Scanner. Single pool of 4 3TB drives, on Windows 8.1. I've set folder options to show hidden and system files. I removed one of the drives from the pool, and DrivePool dutifully transferred its files off the disk. An identical disk has been re-added to the pool. Subsequently, I noticed the following on two of the remaining drives: Within the primary pool partition folder there has appeared another pool partition folder with the same GUID, and within this folder, another folder with the same GUID, and so on, five levels deep. There is also a .covefs folder in each of these nested folders. Is this normal? I ask partly because I've been unable to delete another, separate, multi-nested folder structure on the pool (file not present errors), and am concerned there might be some type of creeping file system corruption going on. Chkdsk and Scanner scans are OK, however.
×
×
  • Create New...