How to prevent folder deletion and still allow modifying it's content?

[mixtly]

Is there a way to prevent folder deletion while still allowing adding/modifying/removing files and folders inside relevant folder.

Possible use case: some folders are 'Song Playlists'. Deleting them would just have to delete the Playlist, not the actual songs which may belong to the particular playlist. However deleting a song inside playlist should just remove the song from relevant playlist.

Now, for some playlists user doesn't have permission to delete them, but can alter their's content (add, remove, edit songs). Currently, if user tries to delete playlist, first all the songs are removed and at the end playlist is deleted which can fail at that point, but that's too late - all songs are already deleted and that wasn't desired action.

Ideally, there would be a way to not allow folder deletion in the first place, so that songs in it are also not tempted for deletion.

Then, though unrelated to this group, Finder Sync Extension could be created which would offer context menu option to delete Playlist alone (without firing requests for each song in the playlist).

There is a similar question in the group:

https://groups.google.com/forum/#!topic/osxfuse-group/xntsDlbBYX4

but what I'm asking here is if there is a way to forbid folder deletion and so not attempt it's subcontent deletion, but still allow deletion of it's internal content?

[Sam Moffatt]

Hi there,

Fundamentally at the OS level what's happening is to unlink a directory requires you to unlink all the contents of the directory first. This is why you see prior to a folder delete all of it's contents being removed. Per my earlier reply, there isn't a way that you can stop this because that's how the OS/FS interaction occurs. 

Similar to the earlier reply, what you could potentially do is cache up the local deletes and then look for a folder delete. After this happens you could block the folder delete and then restore the cached data. It's important to appear consistent during the initial deletes (e.g. the FS should report the files are deleted) however at the point where you get the delete for the top level object you can restore the files back.

I don't think there is a clean way for an FS interface to block deleting a folder in the way you want.

Cheers,

Sam Moffatt
http://pasamio.id.au

--
You received this message because you are subscribed to the Google Groups "OSXFUSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-group+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mixtly]

Thank you Samuel,

so if I understand you correctly, an approach should be like:

1. cache deletions with actually 'marking' deletions as successful so that when FS asks for file, FuseDelegate responds that it doesn't exist

2. once silence is noticed (like 2 seconds have past since last delete callback), go through all cached delete requests and try to figure out what folder did the client actually try to delete

3. update the remote server with proper request

Sam Moffatt
http://pasamio.id.au

To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-grou...@googlegroups.com.

[Sam Moffatt]

That's roughly what I'm suggesting. You might be able to tune your threshold down, a second is likely a really long time for these operations. 

You could probably detect the folder delete and at that point restore any deleted files from that directory that were in the cache. The delete of the directory is going to be the last operation so in theory you're going to block that (no permission error or similar) and then when you do that you can restore anything in the local cache. The usual recommendations on making sure you're using appropriate concurrency protections apply here as well because you don't want your FS to commit the cached changes. 

--

Sam Moffatt

http://pasamio.id.au

Note: I'm not at my desk, responses may be delayed. Apologies for the typos, smartphones aren't all that smart.