I am making a Flask web app in PyCharm on Linux virtual machine. I recently noticed a strange file named ''$'a0406' directly in the project’s directory. Any clues what it might be and if it’s safe to remove?
Here’s the output of pip freeze in case you need it:
alembic==1.4.1 blinker==1.4 Click==7.0 Flask==1.1.1 Flask-Login==0.5.0 Flask-Mail==0.9.1 Flask-Migrate==2.5.2 Flask-Moment==0.9.0 Flask-SQLAlchemy==2.4.1 Flask-WTF==0.14.3 itsdangerous==1.1.0 Jinja2==2.11.1 Mako==1.1.2 MarkupSafe==1.1.1 pkg-resources==0.0.0 python-dateutil==2.8.1 python-editor==1.0.4 six==1.14.0 SQLAlchemy==1.3.13 Werkzeug==1.0.0 WTForms==2.2.1
Edit: I moved the file to another directory according to Lee’s suggestion. Everything worked anyhowe. I also opened the file and it turned out to be generated by SQLAlchemy. Opening the file in a text editor yields this following bizarre content:
Help on SQLAlchemy in module flask_sqlalchemy object: class SSQQLLAAllcchheemmyy(builtins.object) | This class is used to control the SQLAlchemy integration to one | or more Flask applications. Depending on how you initialize the | object it is usable right away or will attach as needed to a | Flask application. | | There are two usage modes which work very similarly. One is binding | the instance to a very specific Flask application:: | | app = Flask(__name__) | db = SQLAlchemy(app) | | The second possibility is to create the object once and configure the | application later to support it:: | | db = SQLAlchemy() | | def create_app(): | app = Flask(__name__) | db.init_app(app) | return app | | The difference between the two is that in the first case methods like | :meth:`create_all` and :meth:`drop_all` will work all the time but in | the second case a :meth:`flask.Flask.app_context` has to exist. | | By default Flask-SQLAlchemy will apply some backend-specific settings | to improve your experience with them. | | As of SQLAlchemy 0.6 SQLAlchemy | will probe the library for native unicode support. If it detects | unicode it will let the library handle that, otherwise do that itself. | Sometimes this detection can fail in which case you might want to set | ``use_native_unicode`` (or the ``SQLALCHEMY_NATIVE_UNICODE`` configuration | key) to ``False``. Note that the configuration key overrides the | value you pass to the constructor. Direct support for ``use_native_unicode`` | and SQLALCHEMY_NATIVE_UNICODE are deprecated as of v2.4 and will be removed | in v3.0. ``engine_options`` and ``SQLALCHEMY_ENGINE_OPTIONS`` may be used | instead. | | This class also provides access to all the SQLAlchemy functions and classes | from the :mod:`sqlalchemy` and :mod:`sqlalchemy.orm` modules. So you can | declare models like this:: | | class User(db.Model): | username = db.Column(db.String(80), unique=True) | pw_hash = db.Column(db.String(80)) | | You can still use :mod:`sqlalchemy` and :mod:`sqlalchemy.orm` directly, but | note that Flask-SQLAlchemy customizations are available only through an | instance of this :class:`SQLAlchemy` class. Query classes default to | :class:`BaseQuery` for `db.Query`, `db.Model.query_class`, and the default | query_class for `db.relationship` and `db.backref`. If you use these | interfaces through :mod:`sqlalchemy` and :mod:`sqlalchemy.orm` directly, | the default query class will be that of :mod:`sqlalchemy`. | | .. admonition:: Check types carefully | | Don't perform type or `isinstance` checks against `db.Table`, which | emulates `Table` behavior but is not a class. `db.Table` exposes the | `Table` interface, but is a function which allows omission of metadata. | | The ``session_options`` parameter, if provided, is a dict of parameters | to be passed to the session constructor. See :class:`~sqlalchemy.orm.session.Session` | for the standard options. | | The ``engine_options`` parameter, if provided, is a dict of parameters | to be passed to create engine. See :func:`~sqlalchemy.create_engine` | for the standard options. The values given here will be merged with and | override anything set in the ``'SQLALCHEMY_ENGINE_OPTIONS'`` config | variable or othewise set by this library. | | .. versionadded:: 0.10 | The `session_options` parameter was added. | | .. versionadded:: 0.16 | `scopefunc` is now accepted on `session_options`. It allows specifying | a custom function which will define the SQLAlchemy session's scoping. | | .. versionadded:: 2.1 | The `metadata` parameter was added. This allows for setting custom | naming conventions among other, non-trivial things. | | The `query_class` parameter was added, to allow customisation | of the query class, in place of the default of :class:`BaseQuery`. | | The `model_class` parameter was added, which allows a custom model | class to be used in place of :class:`Model`. | | .. versionchanged:: 2.1 | Utilise the same query class across `session`, `Model.query` and `Query`. | | .. versionadded:: 2.4 | The `engine_options` parameter was added. | | .. versionchanged:: 2.4 | The `use_native_unicode` parameter was deprecated. | | Methods defined here: | | ____iinniitt____(self, app=None, use_native_unicode=True, session_options=None, metadata=None, query_class=<class 'flask_sqlalchemy.BaseQuery'>, model_class=<class 'flask_sqlalchemy.model.Model'>, engine_options=None) | Initialize self. See help(type(self)) for accurate signature. | | ____rreepprr____(self) | Return repr(self). | | aappppllyy__ddrriivveerr__hhaacckkss(self, app, sa_url, options) | This method is called before engine creation and used to inject | driver specific hacks into the options. The `options` parameter is | a dictionary of keyword arguments that will then be used to call | the :func:`sqlalchemy.create_engine` function. | | The default implementation provides some saner defaults for things | like pool sizes for MySQL and sqlite. Also it injects the setting of | `SQLALCHEMY_NATIVE_UNICODE`. | | aappppllyy__ppooooll__ddeeffaauullttss(self, app, options) | | ccrreeaattee__aallll(self, bind='__all__', app=None) | Creates all tables. | | .. versionchanged:: 0.12 | Parameters were added | | ccrreeaattee__eennggiinnee(self, sa_url, engine_opts) | Override this method to have final say over how the SQLAlchemy engine | is created. | | In most cases, you will want to use ``'SQLALCHEMY_ENGINE_OPTIONS'`` | config variable or set ``engine_options`` for :func:`SQLAlchemy`. | | ccrreeaattee__ssccooppeedd__sseessssiioonn(self, options=None) | Create a :class:`~sqlalchemy.orm.scoping.scoped_session` | on the factory from :meth:`create_session`. | | An extra key ``'scopefunc'`` can be set on the ``options`` dict to | specify a custom scope function. If it's not provided, Flask's app | context stack identity is used. This will ensure that sessions are | created and removed with the request/response cycle, and should be fine | in most cases. | | :param options: dict of keyword arguments passed to session class in | ``create_session`` | | ccrreeaattee__sseessssiioonn(self, options) | Create the session factory used by :meth:`create_scoped_session`. | | The factory **must** return an object that SQLAlchemy recognizes as a session, | or registering session events may raise an exception. | | Valid factories include a :class:`~sqlalchemy.orm.session.Session` | class or a :class:`~sqlalchemy.orm.session.sessionmaker`. | | The default implementation creates a ``sessionmaker`` for :class:`SignallingSession`. | | :param options: dict of keyword arguments passed to session class | | ddrroopp__aallll(self, bind='__all__', app=None) | Drops all tables. | | .. versionchanged:: 0.12 | Parameters were added | | ggeett__aapppp(self, reference_app=None) | Helper method that implements the logic to look up an | application. | | ggeett__bbiinnddss(self, app=None) | Returns a dictionary with a table->engine mapping. | | This is suitable for use of sessionmaker(binds=db.get_binds(app)). | | ggeett__eennggiinnee(self, app=None, bind=None) | Returns a specific engine. | | ggeett__ttaabblleess__ffoorr__bbiinndd(self, bind=None) | Returns a list of all tables relevant for a bind. | | iinniitt__aapppp(self, app) | This callback can be used to initialize an application for the | use with this database setup. Never use a database in the context | of an application not initialized that way or connections will | leak. | | mmaakkee__ccoonnnneeccttoorr(self, app=None, bind=None) | Creates the connector for a given state and bind. | | mmaakkee__ddeeccllaarraattiivvee__bbaassee(self, model, metadata=None) | Creates the declarative base that all models will inherit from. | | :param model: base model class (or a tuple of base classes) to pass | to :func:`~sqlalchemy.ext.declarative.declarative_base`. Or a class | returned from ``declarative_base``, in which case a new base class | is not created. | :param metadata: :class:`~sqlalchemy.MetaData` instance to use, or | none to use SQLAlchemy's default. | | .. versionchanged 2.3.0:: | ``model`` can be an existing declarative base in order to support | complex customization such as changing the metaclass. | | rreefflleecctt(self, bind='__all__', app=None) | Reflects tables from the database. | | .. versionchanged:: 0.12 | Parameters were added | | ---------------------------------------------------------------------- | Data descriptors defined here: | | ____ddiicctt____ | dictionary for instance variables (if defined) | | ____wweeaakkrreeff____ | list of weak references to the object (if defined) | | eennggiinnee | Gives access to the engine. If the database configuration is bound | to a specific application (initialized with an application) this will | always return a database connection. If however the current application | is used this might raise a :exc:`RuntimeError` if no application is | active at the moment. | | mmeettaaddaattaa | The metadata associated with ``db.Model``. | | ---------------------------------------------------------------------- | Data and other attributes defined here: | | QQuueerryy = None
Now the questions are:
- Why the strange filename?
- Is it safe to remove this file since the content seems corrupt?
Edit: I consider it solved. The file is safe to keep and like Lee said in the comments section, the filename is automatically generated, which would explain why it looks strange to the human eye.
Advertisement
Answer
It’s an auto generated name. It’s easy for code to store and retrieve a file name that’s a random set of alphanumeric symbols.
Generating out the name through some random algorithm is a lot easier than a dev having to manage file names for a random amount of files currently being used.