LabVIEW
déplacer dossier vers la corbeille
This is exactly the work of the "Delete" function instead, let the OS take care of where it needs to move stuff on Delete.
Well, the trash is a feature of the Window shell, not the actual Windows kernel. The windows shell is pretty much everything File Explorer and then some more and is really a collection of all kinds of interfaces put together in a sometimes rather hackish manner. It's origins are for a large part in the original Internet Explorer and what they created with the File Explorer as a replacement of the File Manager from Windows 3.x days.
The LabVIEW API is almost exclusively interfacing to the low level Win32 API with a few exceptions. So the trash is not a real file location on disk but a virtual Windows shell name space (that ultimately of course maps to some storage on disk but its organization is a private implementation detail of the Windows shell and not to be assumed to stay consistent between versions) and in fact has changed many times over the course of the different Windows versions.
So there is really no way of accessing the trash through a file function. The LabVIEW Delete function calls the Windows API function DeleteFile() respectively RemoveDirectory() Win32 API and they directly remove the specified object, without going through start and without collecting 200 dollar. 😁
If you want to move files to the trash you have to call the very famous (in a negative way) SHFileOperation() API. This one is not only nasty to call from LabVIEW because of its single parameter, which is a structure that contains several string pointers, but also because someone in the Windows shell development team figured that it is a VERY smart idea to make one single function that will move, copy, trash and delete, files, directories and entire hierarchies, with or without progress dialog and event support as well as callback information for applications. It's early implementations were very well known for doing very weird things if the various parameters in the data structure were not sanitized and logical. For instance it would happily attempt to copy a hierarchy into itself and make a total mess of your harddisk. Somewhere around Windows 7 the entire function was fundamentally rewritten and is since a lot more sane to call but it's still a monster function that tries to cook a meal, prepare coffee, keep your cat happy and along the way prepares your newspaper for you to read.
API support for the trash is similarly troubled on both MacOS and Linux. On MacOS the official API to do this thing has several times changed and then been depreciated, with at times no good alternative in between. On Linux its not at all present in the kernel but rather a feature of the specific desktop. There is a sort of standard that "recommends" common paths for the trashbin but each desktop such as KDE, Gnome, XFCE, Slim and XKCD tend to have their own idea what is the correct way to do that and how to store meta information such as when the files were deleted and what were their original location. Most use some kind of database format for this meta information and you have to call the desktop specific tool to have these entries updated. If you just move the files in there yourself, they will be present there, but the desktop manager is still not able to restore them to the original location.
@galbich wrote:
Bonjour,
merci pour votre repense, y a-t-il des DLL qui peuvent déplacer les dossiers vers la corbeille ?
merci d'avance
Yes you would need to call SHFileOperationA(SHFILEOPSTRUCTA fileop) in shell32.dll. And that SHFILEOPSTRUCTA struct is a nasty one to interface from LabVIEW directly. If you love to see your computer crash often and hard, you can try it out but the real solution for this is to write a wrapper DLL that provides a function with the necessary interface with the required elements as separate parameters and then puts them into this struct on the C side before calling the API. Otherwise you have to start playing C compiler yourself.
Basically you need to assign FO_DELETE to the wFunc element, the pointer to the FULLY QUALIFIED (NO RELATIVE PATHS!!!!) path string as double NULL terminated string to the pFrom element and FOF_ALLOW_UNDO to the wFlags member. All the other elements in that struct should be cleared to 0 just for safety. And if you want to do this all in LabVIEW you have to watch out that:
- the memory layout for this structure is significantly different for 32-bit and 64-bit
- there are alignment issues where you have to account for additional filler bytes in between elements
If you want to wait a little more you may be interested to know that I have been working on this for some time as part of a new version for the OpenG ZIP library. I decided to create an entire helper library of file IO functions, that allows for long path names (up to 32k characters) and the entire Unicode character set (although using that from within LabVIEW is a little tricky but possible). It also contains functions to support Symbolic Links and a Delete that has the option to move things to the trash bin. It's still in the testing phase but I hope to have a fully working version for at least Windows and Linux early next year. Although the trash bin functionality on Linux is as I already pointed out at best a feeble attempt, there simply is no way to make it universally applicable for all Linux platforms. None, Nothing, Niente!
