Lucas De Marchi <lucas.demarchi <at> profusion.mobi> writes: > > While that would work in theory, it also requires one to have an > > fdescfs mounted and still isn't very portable. The renaming is > > indeed a hack -- what I wonder is if it is worth keeping. > > As > > you noticed, any code path that calls stat() to verify if the file > > > indeed exists would fail.
Why? The patch keeps the file created in /dev/shm, /tmp or whatever around for longer than the lifetime of _create_tmpf() precisely to make the stat() not fail. > You'd need to investigate the code paths and refactor them: - If you > receive an fd, stat(filename, ...) should not happen -> and the > filename should be used for logging purposes and similar stuff. That's what I am doing -- depending on how you view it, evas_object_image_memfile_set() is just a hack to make evas_object_image_file_set() work with memory addresses instead of actual files, and it achieves that by creating a temporary file and mmap()ing the memory addresses to that file. The rest of the codepath is just evas_object_image_file_set() being called, so nothing needs to change. > Postponing the removal like you did IMO is a hack to fix another > hack. So, either do the same thing as in Linux (rename to something > will continue to exist) or change all code paths. Erm, that's what my patch does, I think :-) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
