Folders on SnapLock shares cannot be renamed!

[#1]

Hello, people!

When I make a SnapLock volume, open a CIFS share on it and try to create a new folder in it - it's automatically created & called "New Folder" (Windows default) and I cannot rename it!

Sure, I can use qtrees instead, but if there are not retention policies and auto_commit is turned off - folders placed in that share should be accessed, modified and deleted in accordance with user's privileges. Just like with files.

I can access it, delete it, but not modify it.

What's the catch? Why is a folder instantly set to read-only??

Thanx,

Igor

[#2 · Accepted solution]

HI Igor,

Not sure if  you found the solution...but your answer is in the DOT Archive and Complaince guide.

Was it a SLE or SLC volume ?

The data that is committed to the WORM state on a SnapLock volume cannot be changed or deleted

before its retention date. However, you can change or delete the empty directories and

files that are not committed to a WORM state. Directories do not behave any differently than they would on regular

volumes, with the exception that they cannot be renamed or moved once created. It is a requirement

for regulatory compliance that WORM data be not only non-erasable and non-rewritable, but it must

also be locked down in the same location at which it was created. In the case of WORM implementation,

this means that the directory path to WORM

files must be locked down and should never change.

In Data ONTAP 7.0 and later, WORM

files can be deleted after their retention dates have been reached.

The retention date on a WORM

file is set when the file is committed to the WORM state, but it can be

extended at any time. The retention period can never be shortened for any WORM

file.

The data that is committed to the WORM state on a SnapLock volume cannot be changed or deleted

before its retention date. However, you can change or delete the empty directories and

files that are not

committed to a WORM state. Directories do not behave any differently than they would on regular

volumes, with the exception that they cannot be renamed or moved once created. It is a requirement

for regulatory compliance that WORM data be not only non-erasable and non-rewritable, but it must

also be locked down in the same location at which it was created. In the case of WORM implementation,

this means that the directory path to WORM

files must be locked down and should never change.

In Data ONTAP 7.0 and later, WORM

files can be deleted after their retention dates have been reached.

The retention date on a WORM

file is set when the file is committed to the WORM state, but it can be

extended at any time. The retention period can never be shortened for any WORM

file.

Were you able to delete it as empty directories you should be able to delete it. ??

Kavan

[#3]

Hi, Kavan!

Thanx for your reply, I guess I missed that part from the Compliance Guide. Oops! =)

Yes, the volume (aggregate) was SLE. I am able to delete the folder if it's empty, of course.

The only thing that puzzled me was not being able to rename a newly created, completely empty folder... Which means, in Windows environment, all you can create is "New Folder".

Still, you can work around it by creating a folder structure with desired names, locally, and than simply copy it to a SLE share. Or, you can use qtrees.

Igor

[#4]

I know that this question was asked a long time back and it is already answered. However, still posting as I could find a more appropriate answer -

An important consideration for SnapLock storage is how directories are treated. Directories, once created on a SnapLock volume, cannot be renamed regardless of their access permissions. This is an important consideration when using the Microsoft Explorer tool to create a new folder. The first step Explorer takes is creating a directory called New Folder, then attempts afterward to rename this to something more useful, which is not possible on a SnapLock volume. Manually creating directories on SnapLock volumes in either the Microsoft or the UNIX environment is better handled using mkdir in a command line interface. While directories cannot be renamed, they can be deleted as long as no files committed to WORM state are contained within their hierarchy.