Moving directories

[bchaintreuil]

Hi,

As it's wrote in the README, it's impossible to move directories... (whereas it's available on hubiC)

But I don't understand why, as moving directory is equal to copy it (and its content) and after that, remove it... (and these features is actually active...)
as Octave said in the mails he sent in the Cloud/hubiC mailing list, the future rsync/ftp/etc... gateway who will be soon available will be based on the use of svfs on docker container to work... and maybe these protocols may use the mv syscall ? And client may need to have this feature available ?

As an example, I would like to mount my PCS and use it as primary storage on my Owncloud server, without using the External storage support (who don't work... Maybe a bug in Owncloud, or in the swift api at ovh... I don't know, see my issue here : owncloud/core#20968), and I can't beacause Owncloud need the capability to move folders (Desktop client)

[xlucas]

Hello, and thanks for reporting in.

If you call the rename() syscall in a standard linux-comptabile fs you are most of the time actually creating a new "meta-link" by simply adding a new direntry and removing the old one but the usage on the underlying device doesn't change.

The rename() syscall implementation in svfs is indeed a copy + delete operation, and this is the problem : users may end up with very large and unexpected usage growths. This may not appear as a real issue for hubic users but PCS billing is triggered from container usage (per GB).

I think a good way to get through this would be to add two mount options :

• file_rename=[true|false]
• dir_rename=[true|false]

Both disabled by default and we would let an advised user decide if he allows these operations to take place or not.

[bchaintreuil]

@xlucas So if I have understand, it's actually implemented for renaming file/folder, it's possible to implement this for moving ?

[xlucas]

No. When you run mv source destination you actually use the rename() syscall and this is not implemented in svfs if the source is a directory.

As detailed in my previous answer, we could, maybe, implement this and bring new options, however there's a caveat on usage growth.

Another issue is that while this operation only consist of updating filesystem metadata in common linux filesystems, this is a plain copy + delete operation for object stores like Swift because there's no such thing as a move operation. In other words, implementation would require moving all objects within the source directory as well, recursively calling rename() while the client may not expect this to happen.

[bchaintreuil]

I think I've understand, and what you propose give us the choice to enable or not a such functionality, so it's maybe the best thing

Thanks for your answer :) !