Octoprint: [Request] Please auto delete the .FileName files we get when uploading from a Mac over SMB file share to the watch folder.

Created on 7 Apr 2018  路  23Comments  路  Source: OctoPrint/OctoPrint

Please auto delete the .FileName files we get when uploading from a Mac over SMB file share to the watch folder.

Thanks! loving this software so far! (i'm new only a few weeks!)

done request

Most helpful comment

The maintenance branch (so what is going to be 1.3.9) is going to ignore hidden files (= files starting with .). However 1.3.9 is not released yet, so to test this out you'll need to manually check out the branch - or wait until the first RC of 1.3.9 which you'll then find on the "Maintenance RCs" release channel.

All 23 comments

sorry, forgot to mention, a mac sends 2 files to the SMB file share. they have the same name but one starts with .

Been a while since I used OSX but is there an option in finder to NOT create those files on SMB shares?

To be honest, this sounds more like something that the OS should stop doing instead of having a piece of software running in a completely different environment work around.

It would make sense though to ignore files starting with . in general, at least when installed on Linux since they would be hidden in the file list anyhow (. signifies hidden files under Linux).

ntoff - I'm not aware of a way to disable the meta data ._ files, and to be honest, I want them in most situations. they are invisible and retain important meta data about my files.

foosel - this sounds like something the OS should do? seems like a simple thing to include in application when it's moving files form the watched folder. move the and delete the . files with the same file names.. most apps would not import them.

I'm not aware of a way to disable the meta data ._ files

https://www.google.com/search?q=osx+disable+appledouble+on+smb

It just disables them for network shares, not the entire OS.

Ok, as I said, I don鈥檛 want it disabled for SMB file shares, I need the metadata in most situations.
If it is speaific to a SMB share and not all then ok.
But my NAS is SMB and I want all the ._ data to be retained?

Perhaps I can sort out how to get samba on my octopi to do this...

veto files = /._*/.DS_Store/

(though I truly believe the application should just know not to import files it can鈥檛 use)

maybe after I get around to a clean install, because after experimenting with ways to do secure remote access with VPN and then removing that, bonjour and samba doesn鈥檛 work properly anymore...

Ok, as I said, I don鈥檛 want it disabled for SMB file shares, I need the metadata in most situations.

ok, my bad, I thought you were only interested in them for local files. I turn them off for shared folders because I have a mixed environment and windows doesn't need them, and OSX has no business making those files on a windows machine's share.

Any files placed in the watched folder that start with a . will be ignored going forward. That also means they'll stay there (they won't be deleted or anything).

Above commit is available on maintenance, soon devel, to be released with 1.3.9.

Wait, you are going to opt for leaving orphaned ._ files hidden in the watch folder as the Solution? Wow... I would rather you let them be imported then, so i can actually delete them my self without jumping hoops to do so...

@foosel Deleting, rather than ignoring the .Filename file, would be a more preferable solution for Apple users. If there is a concern about deleting a file, adding an option or creating specific plugin could make this action explicit.

Also, thanks for developing this project for the community!

Wow...

Oh come on, you are making it sound like I kicked a puppy. It's not like those files are unmanageable - if you can place files into that folder from your Mac, you can also delete files left in that folder from your Mac.

I really don't want start deleting files that OctoPrint doesn't actually handle.

I'm open to introducing a hook to allow further file processing on the watched folder by plugins. Alternatively, a configuration option to delete unhandled files (defaulting to off). That's something someone else would need to provide though through a PR (against maintenance). I'm swamped with tasks already. So if you want it, get to it.

Alternatively, a configuration option to delete unhandled files

and for whoever does implement such a feature, make it also contain a user configurable list of files to NOT delete, in case someone adds their own "metadata" files or notes into the uploaded folder to keep track of files they've uploaded and the settings used therein.

Nah... just have it default to not delete stuff it doesn't know to handle. Whoever decides to flip it on then has to live with that.

no you didn't kick a puppy. I appreciate your work on this software.

._ files are invisible, they are generated by the Mac on purpose because SMB and the destination file system do not support the extended meta data a Mac maintains on files. (so when you move something back form your SMB file share, you didn't loose anything. such as from a NAS)

I have no idea, maybe the Mac will auto clean up ._ files left behind it's self.
I haven't installed the latest version of Octoprint possibly with this feature to see... I to am very busy with other things, and haven't had the time to tinker under the hood.

I have many friends who seem to live in the terminal, and thats great. I choose not to...
If it's left to me to manage the orphaned ._files, the only way to do would be from the terminal.

All I'm requesting is this. When you move files from the watched folder to the directory they live in as imported. Automatically trash any that start with ._
and if you want to be sure it's ok. these files have the exact same file name as the file it belongs with.

for example

vase4.stl
._vase4.stl

thats it.

Adding a hook that lets plugins manipulate the files sounds more complex and could become a security risk?

Every plugin in a way is a security risk - it runs on your machine and could play around with stuff on your file system even without a hook already. And yep, would be slightly more complicated. More flexible too though. Might even be possible to do stuff like "if file has prefix x upload it to folder y", effectively overriding the default behaviour.

Maybe my request is one of those sounds simple but is more complex things. (And the complex request would be simple)

All I care about are Apple Double files...
They have the same file name but have ._ as a prefix.

It鈥檚 probably good to continue to ignore all . Files on import as well. Since they are invisible and likely not going to be a 3D file to process.

But just leaving the Apple double ._ files behind leaves a mess of files many people my not know to look for and remove...

I haven鈥檛 had a chance to test if Apple auto cleans up orphaned ._files

All I care about are Apple Double files...

Ok, picture the following scenario. OctoPrint is modified to not only ignore but actually clean up those ._ files your Mac produces. Version 1.3.9 is released, everyone is happy. Except Joe, who happens to run $OtherOS, has been struggling with a similar issue with some files their SMB client auto creates there and now wants an exception too. So we add this. OctoPrint 1.3.10 is released, everyone including Joe is happy. Except Evelyn who just recently installed this fancy new indexing software on her NAS you see, and that now creates these other files and .... You see where I'm getting there?

I know the "slippery slope" argument is frowned upon, and rightly so in most cases. But I've been running this project now for over five years, and if I hadn't been as skeptical about very specific things like this, the settings dialog would now look like this:

image

stuff would be way more tricky to set up to make sure no of the special cases interfere with normal operation, and probably no one would be happy, least of all me.

I agree configurations shouldn鈥檛 require 10,000 hours or training to understand, and flexibility is also important.

Making things easy for end users is never easy for the developers...

For now, ._ files are the issue, and perhaps there is a way to make that filter configurable for possible future needs.

I think we can both agree that the best thing for end users is to somehow be sure to not import files Octoprint doesn鈥檛 process.

I will install the latest version, that I believe you said should now ignore all . files? (Invisible files) and maybe Apple鈥檚 engineers have already delt with garbage collection of orphaned Apple Double files? We will see...

The maintenance branch (so what is going to be 1.3.9) is going to ignore hidden files (= files starting with .). However 1.3.9 is not released yet, so to test this out you'll need to manually check out the branch - or wait until the first RC of 1.3.9 which you'll then find on the "Maintenance RCs" release channel.

@foosel Thanks. Will this include the hook?

I'm open to introducing a hook to allow further file processing on the watched folder by plugins. Alternatively, a configuration option to delete unhandled files (defaulting to off). That's something someone else would need to provide though through a PR (against maintenance). I'm swamped with tasks already. So if you want it, get to it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dkingsjr picture dkingsjr  路  5Comments

FormerLurker picture FormerLurker  路  5Comments

ModischFabrications picture ModischFabrications  路  3Comments

halkeye picture halkeye  路  4Comments

JohnOCFII picture JohnOCFII  路  5Comments