次の方法で共有

Rearranging a Groove-synchronized Windows folder

  • [アーティクル]

 

When you use a folder in your daily work, you naturally find yourselves moving things around. For example, shortly after I started blogging, I realized that my work documents folder had become cluttered with half-written article ideas, so I changed the names of these files to start with "do- " and moved them into my blog and solution subfolders, both of which had previously been only for finished articles.

We all make these sorts of changes, right? However, since work documents is the root of a Groove file sharing workspace, I had to keep in mind how the changes might affect performance. Here are a few things to be aware of when you start reorganizing a GFS folder.

Factors affecting workspace performance

Consider what happens when you rename a file. Workspace members who are logged into Groove need to process the new file name, but unless you have a huge number of files, this isn't a big deal. However, if a member is not logged in at the time of this operation, their Groove installation will only see the results of the change -- an apparent file deletion and a new file. In this case, the entire file is resent (or, if it exceeds automatic download limits, it must be fetched again).

If you rename a subfolder, the same conditions apply, but now if a member is offline when you perform the move they must re-fetch everything in that folder.

But what if you are not running Groove when you make these changes? After all, you can use a Groove-synchronized folder when Groove isn't active. The same problems apply. Since Groove has no information about operating system events that occurred when it was not an active process, each renaming operation becomes deleting a file followed by adding a file, and those changes must be sent to every workspace member.

In some rare cases, Groove can miss a renaming anyway. This usually happens if there is a lot of disk activity going on. If Groove doesn't get the file system events close enough together, it may not succeed in matching them and detecting that an existing file has been renamed.

Moving a file is similar, if you move the file within a directory. However, if you have a file several folders deep and move it to the top level, or to a parallel folder with a high divergence point, Groove has to make more changes to the workspace record. If you move a large volume of data this way, Groove may not be able to send all the changes effectively. In this case, the entire workspace will be resent to all members.

In my case, these changes all had to be sent to my other computer, but because I am the only member of the workspace, I didn't need to worry about offline members. I made sure both computers were active in Groove, and that I wasn't running anything disk intensive on either one, and everything went smoothly.

Recommendations

Plan:

  • Decide which files are moving where
    • Avoid renaming large directories
    • Avoid any single operation that will affect more than 200 files
    • Avoid rearranging files in deeply nested folder
  • Choose a time to make the change. Ideally, it would be when network usage is low, but most members are online. Obviously, these two states won't usually coincide, so take your environment into account.
  • It is better to make small changes frequently than overly large changes less often. For example, if you move files for closed projects once a month and have had problems, consider doing it once a week.

Communicate:

  • Let workspace members know that they may see significant data transfer in Groove
  • Ask workspace members to stay online in Groove until changes are complete

Execute:

  • Ensure that you are logged into Groove before making the changes
  • Move files in batches, if you need to move more than 200 files. For example, move 100 files, wait for the changes to disseminate to end users, and then move the next batch
  • If you need to move files to or from a deeply nested folder, move only a few files at a time

With these guidelines, you should be able to rearrange your GFS folders without synchronization problems.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    May 06, 2009
    Hi Moonlight great to hear from you :-) I will of-course defer to your insiders knowledge. Must say however that i have not "seen" this batch delete happen - but then i am just looking at the space bloat - quite possible that some deleted matter but not is removed but (some) excess space usage still remains. the principle that i find safe to pass on to users is however that we can't expect normal  space reclamation so be careful cheers