Category Archive: 2 Redesign (Scan a share) (R)

Project typ “Scan Resources”

1. For each Share a new project

1.1. Reading directories and permissions

In migRaven one always works with a project. This is the logical unit, which is to be processed. This can, for example, be a share or a directory below a share. In ideal cases it is the point, which is also mounted by the users or is connected in the DFS. Thereby it is ensured, that all permissions – including the list permissions – are correctly created by migRaven.

1.2. Best Practice: for each Share a new project is placed

When you define the individual shares as standalone projects, then you have time to process this in peace and “Step by Step” to copy the data in the new directories and then provide these to the users.

Read the rest of this entry »

ACL Errors

If errors appear during scanning your shares, then these are listed during scanning.

Frequent errors are for example, too long path names. The path name is composed of the computer names and all directory names down to the lowest directory. The complete length must not exceed 260 characters.

An additional problem could be that despite administrator rights you have no access to a directory. (Only the legitimate owner has the rights, the administrator has none.) In that case, the error message “Access to ACL not permitted” appears.

Read the rest of this entry »

The Green Meadow

1. Necessity of the “Green Meadow”

If the authorizations of a share are to be migrated to a server, then there are two possibilities. Either one migrates within the share or one creates a target share parallel, which one designs and which one finally names the source share. The first variant is possible with migRaven, contains however old and new authorizations and requires rework. The second variant with the structure of a parallel share is only sensible. Then which name should one give to the parallel share? Should the source share be renamed anyway, one simply give the target share the new name. The name should mostly be maintained, i.e. the target share should retain the same name like the source share. Two same release names on a server are however not possible. Thus the new share gets first any name, e.g. “Green Meadow”. After the migration, i.e. after creating the authorizations and after copying the data, the old share must be renamed and the new share can maintain the original name of the old share.

Read the rest of this entry »